In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Also, don't assume that the key passed in is just a string. It could well
> be a string/hashval pair, or a string/hashval/magic triple, and we use the
> fast method with the others as fallbacks.
In other words, it's just a generic iterator state object... The
way I'd like to see things work is that hashes, arrays etc have a
vtable method that returns an iterator object. That iterator object
then has whatever opaque data is needed to maintain position plus
it's own vtable that can advance the iterator, return the current
value, etc. So we get something like this:
it = hv->new_it()
while (it->valid())
{
sv = it->value();
...
it->next();
}
Whether we choose to expose this internal behaviour by allowing
multiple iterators at the language level is, to me, a completely
separate issue.
If iterators are (internally) first class objects like this then
they can be used in places where arrays are otherwise used - if an
iterator is found where an array is expected it is simply advanced
to completion to recover the values to operate on. Of course this
can, where possible, be done lazily.
So grep on an iterator might just construct a new iterator that
encapsulates the original iterator and a condition and has a next
method that skips any values from the underlying iterator that
don't match the condition.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...Hey, don't ask me, I'm just an Anthropomorphic Personification.
