Had to add a new metaclass for Object since it now has its own static method so we
can't just use Class as its metaclass. (We don't want *every* class to have a same(_,_)
static method.)
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.
- "\x" escape sequence to put byte values in strings: "\x34"
- String.byteAt(index) gets value of byte in string.
- String.bytes returns a raw sequence of bytes for a string.
- String.codePointAt(index) gets the code point at an offset as a raw number.
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.
- Allow yielding the main fiber. This exits the interpreter. The
host can resume it by calling a method.
- Allow getting a reference to the current fiber.
