- Remove List.new(_). I was convinced by the issue discussion that
using it is probably a bad idea. We don't want to encourage more nulls
in the world than there are already are. So let's see if we can live
without it and just have List.filled(). That way users think about
what they're creating a list *of*.
- Added some more tests.
- Correctly handle being given a negative size.
This is not implemented on Sequence because, at least for lists and
strings, I think users expect an eager result. Multiplying a string
should give you back a string, not a lazy sequence of repeated
characters.
This also mirrors "+" on strings and lists, which is eager. I like the
idea of having a general guideline that operators are eager.
Repetition is useful for arbitrary sequences, but for that maybe we
should add a "repeat()" method.
Get rid of the separate opt-in IO class and replace it with a core
System class.
- Remove wren_io.c, wren_io.h, and io.wren.
- Remove the flags that disable it.
- Remove the overloads for print() with different arity. (It was an
experiment, but I don't think it's that useful.)
- Remove IO.read(). That will reappear using libuv in the CLI at some
point.
- Remove IO.time. Doesn't seem to have been used.
- Update all of the tests, docs, etc.
I'm sorry for all the breakage this causes, but I think "System" is a
better name for this class (it makes it natural to add things like
"System.gc()") and frees up "IO" for referring to the CLI's IO module.
* Eliminate "new" reserved word.
* Allow "this" before a method definition to define a constructor.
* Only create a default constructor for classes that don't define one.
The methods Sequence.map and Sequence.where are now implemented using
deferred execution. They return an instance of a new Sequence-derived
class that performs the operation while iterating. This has three main
advantages:
* It can be computationally cheaper when not the whole sequence is
iterated.
* It consumes less memory since it does not store the result in a newly
allocated list.
* They can work on infinite sequences.
Some disadvantages are:
* Iterating the returned iterator will be slightly slower due to
the added indirection.
* You should be aware that modifications made to the original sequence
will affect the returned sequence.
* If you need the result in a list, you now need to call Sequence.list
on the result.
This is a bit of a style preference since of course you can always write
the same thing with a for loop. However, I think sometimes the code
looks better when using this method.
It also provides an alternative to Sequence.map for cases where you
don't need the resulting list, and one that becomes especially necessary
when Sequence.map is changed to return a new sequence. The example in
the README.md file was using Sequence.map in a way that required this
alternative in that case.
When possible, they return the actual value from the predicate
instead of always just "true" and "false". This matches && and ||
which evaluate to the RHS or LHS when appropriate.
Returns the number of elements in the sequence that pass the
`predicate`.
It could also have been implemented as:
count(f) { reduce(0) {|a, b| f.call(b) ? a + 1 : a } }
But I considered the simple version more readable.
Also documented Sequence.count.
The previous order, insert(element, index), was counter-intuitive.
I'm not aware of any list API that uses this order. I've checked:
* Ruby Array.insert(index, obj...)
* JavaScript array.splice(start, deleteCount[, item1[, item2[, ...]]])
* C++ / QList::insert(int i, const T & value)
* C++ / std::vector::insert
* Lua table.insert (list, [pos,] value)
* C# List<T>.Insert(int index, T item)
* Java Interface List<E>.add(int index, E element)
* Python list.insert(i, x)
So it seemed to me more like an oversight in Wren.
