Yes, indeed, something cursor-like. Enumerable#getCursor returns a
rewinded Cursor and Cursor#next provides the method to retrieve
subsequent elements. Does something like this already exist for Ruby?
Geert.
···
-----Original Message-----
From: Robert Klemme [mailto:bob.news@gmx.net]
Sent: 03 June 2005 12:15
To: ruby-talk ML
Subject: Re: internal iterators in ruby
Geert Fannes wrote:
So, if I understand well, the problem with iterating over different
enumerables synchronously has to do with the absence of a #rewind and #next method for enumerables. The Generator class solves this using
the slow #callcc method and allows one to step through the
Enumerable#each method, element by element. Wouldn't it be better if
the enumerable required a #rewind and #next method and constructs the #each method out of these instead of doing the reverse using #callcc?
No, this would not be better because then you would have to place
iteration state into the Enumerable which is at least ugly (it wastes
memory most of the time, i.e. the time when there is no iteration) and
it
doesn't allow for multiple concurrent iterations on the same instance.
A better alternative would be to encourage providers of Enumerables to
provide an external iterator for special cases. This then will be more
efficient than callcc.
Yes, indeed, something cursor-like. Enumerable#getCursor returns a
rewinded Cursor and Cursor#next provides the method to retrieve
subsequent elements. Does something like this already exist for Ruby?
Geert.
-----Original Message-----
From: Robert Klemme [mailto:bob.news@gmx.net]
Sent: 03 June 2005 12:15
To: ruby-talk ML
Subject: Re: internal iterators in ruby
Geert Fannes wrote:
So, if I understand well, the problem with iterating over different
enumerables synchronously has to do with the absence of a #rewind and #next method for enumerables. The Generator class solves this using
the slow #callcc method and allows one to step through the
Enumerable#each method, element by element. Wouldn't it be better if
the enumerable required a #rewind and #next method and constructs the #each method out of these instead of doing the reverse using #callcc?
No, this would not be better because then you would have to place
iteration state into the Enumerable which is at least ugly (it wastes
memory most of the time, i.e. the time when there is no iteration) and
it
doesn't allow for multiple concurrent iterations on the same instance.
A better alternative would be to encourage providers of Enumerables to
provide an external iterator for special cases. This then will be
more efficient than callcc.
It combines features from C++ iterators, Java streams, a
text-editor "cursor", and have some other unique features.
···
--- Robert Klemme <bob.news@gmx.net> wrote:
Geert Fannes wrote:
> Yes, indeed, something cursor-like. Enumerable#getCursor
returns a
> rewinded Cursor and Cursor#next provides the method to
retrieve
> subsequent elements. Does something like this already exist
for Ruby?
> Geert.
>
> -----Original Message-----
> From: Robert Klemme [mailto:bob.news@gmx.net]
> Sent: 03 June 2005 12:15
> To: ruby-talk ML
> Subject: Re: internal iterators in ruby
>
> Geert Fannes wrote:
>> So, if I understand well, the problem with iterating over
different
>> enumerables synchronously has to do with the absence of a #rewind and
>> #next method for enumerables. The Generator class solves
this using
>> the slow #callcc method and allows one to step through the
>> Enumerable#each method, element by element. Wouldn't it be
better if
>> the enumerable required a #rewind and #next method and
constructs the
>> #each method out of these instead of doing the reverse
using #callcc?
>
> No, this would not be better because then you would have to
place
> iteration state into the Enumerable which is at least ugly
(it wastes
> memory most of the time, i.e. the time when there is no
iteration) and
> it
> doesn't allow for multiple concurrent iterations on the
same instance.
>
> A better alternative would be to encourage providers of
Enumerables to
> provide an external iterator for special cases. This then
will be
> more efficient than callcc.
>
> Kind regards
>
> robert
__________________________________
Discover Yahoo!
Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html