James Edward Gray II ha scritto:
On Sep 28, 2005, at 5:10 AM, Florian Frank wrote:
I think enumerator should become part of Standard Ruby, because it's so damn useful.
I believe that's the plan. I think all the standard iterators are going to start returning enumerator objects when called without a block.
James Edward Gray II
would'nt it make more sense to have yield work coroutinish when called withouth a block, basically integrating the enumerator functionality in it?
That sounds unnecesarily complex. If it is what I think you
are talking about, you'd return some kind of object with a
continuation when you hit a yield without a block (like a
generator?). An example would help explain what you are
talking about.
I think the current plan with Enumerators sounds better.
--- gabriele renzi <surrender_it@-remove-yahoo.it> wrote:
James Edward Gray II ha scritto:
> On Sep 28, 2005, at 5:10 AM, Florian Frank wrote:
>
>> I think enumerator should become part of Standard Ruby,
because it's
>> so damn useful.
>
>
> I believe that's the plan. I think all the standard
iterators are
> going to start returning enumerator objects when called
without a block.
>
> James Edward Gray IIwould'nt it make more sense to have yield work coroutinish
when called
withouth a block, basically integrating the enumerator
functionality in it?
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
Eric Mahurin ha scritto:
I believe that's the plan. I think all the standard
iterators are
going to start returning enumerator objects when called
without a block.
James Edward Gray II
would'nt it make more sense to have yield work coroutinish
when called withouth a block, basically integrating the enumerator
functionality in it?That sounds unnecesarily complex. If it is what I think you
are talking about, you'd return some kind of object with a
continuation when you hit a yield without a block (like a
generator?). An example would help explain what you are
talking about.
>
> I think the current plan with Enumerators sounds better.
My apologize, I actually meant "Generator" not "Enumerator".
Anyway, yes, just like a Generator, and for all the usage of yield, not just for Enumerables.
This, in my opinion, would be more consistent and preserve the semantic of yielding better than returning an Enumerator, but it seem this decision was already taken in the direction you like, judging from a recent patch.
a) hardly anybody finds use in generators
b) generators are slow because of continuations
c) if the method yielding returns something useful (almost all
methods in Enumerable except each/each_with_index), nothing
would receive this value because the method would return a
generator instead. I think this is only useful for each-like
methods.
If you want external iterators, I don't think Generator is the
way to go. If you want an external iterator, you should build
it into the class (i.e. IO has one) or have another class hold
an index into the collection (look at my cursor package or
Simon Strandgaard's iterator). I may put a generator (probably
Cursor::Enumerable) in my cursor package at some point, but I
don't expect much usage because of the performance.
--- gabriele renzi <surrender_it@-remove-yahoo.it> wrote:
Eric Mahurin ha scritto:
>>>I believe that's the plan. I think all the standard
>>
>>iterators are
>>
>>>going to start returning enumerator objects when called
>>
>>without a block.
>>
>>>James Edward Gray II
>>
>>would'nt it make more sense to have yield work coroutinish
>>when called
>>withouth a block, basically integrating the enumerator
>>functionality in it?
>
>
> That sounds unnecesarily complex. If it is what I think
you
> are talking about, you'd return some kind of object with a
> continuation when you hit a yield without a block (like a
> generator?). An example would help explain what you are
> talking about.
>
> I think the current plan with Enumerators sounds better.My apologize, I actually meant "Generator" not "Enumerator".
Anyway, yes, just like a Generator, and for all the usage of
yield, not
just for Enumerables.
This, in my opinion, would be more consistent and preserve
the semantic
of yielding better than returning an Enumerator, but it seem
this
decision was already taken in the direction you like, judging
from a
recent patch.
______________________________________________________
Yahoo! for Good
Donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
I think this is a case of "b causes a" - python, for instance, uses
generators and people find plenty of uses for them.
martin
Eric Mahurin <eric_mahurin@yahoo.com> wrote:
a) hardly anybody finds use in generators
b) generators are slow because of continuations
I think the main cause of (a) is the presence of internal
iterators in Ruby. Ruby uses internal iterators as a standard
and Python uses external iterators (including generators) as a
standard. I think Python users may go for generators because
they don't have easy to use internal iterators. Maybe Python
makes an optimization to context switching (continuations) for
generators. It probably reuses the same alternate stack space
for each yield whereas ruby's generators create a new
continuation object for each yield.
I just don't see the practical use of generators in ruby
(relative internal iterators). When you end up REALLY needing
something like generator where you pull elements rather than
them being pushed to you (like in an internal iterator), I
think the majority of those cases need a more robust external
iterator interface. Even optimally implemented, a generator
can only efficiently (O(1)) provide getting the next element.
A more general external iterator may also be able to do these:
go in either direction, write, insert, delete, save/restore
position, etc.
--- Martin DeMello <martindemello@yahoo.com> wrote:
Eric Mahurin <eric_mahurin@yahoo.com> wrote:
>
> a) hardly anybody finds use in generators
>
> b) generators are slow because of continuationsI think this is a case of "b causes a" - python, for
instance, uses
generators and people find plenty of uses for them.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005