From: Alexander Kellett <ruby-lists@...>
Date: 2004-08-10T19:05:39+09:00
Subject: Re: FirstEachLast, an extension to the Enumerable module.

On Tue, Aug 10, 2004 at 06:51:15PM +0900, Robert Klemme wrote:
> I strongly disagree.  All sorts of problems arise from this approach:

notice my lack of agreement with myself in any case :)

>  - permanent modification of elements' types
>  - method name collisions
>  - member state collisions
>  - thread problems (1 instance used during two parallel iterations)
> 
> The index clearly belongs to the *iteration* and not the elements.
> Possible solutions:
> 
>  - yield not the instance but an iteration state that has the current item
> as member
>  - use delegator (this avoids permanent changes but has still method
> collision problems)

yes. i'd agree that it belongs to the iteration.
otherwise i would have coded up the thing i mentioned,
but... i've never seen an alternate so never bothered.
could you explain what you mean by delegator in this 
sense? just a usage case example would do. i'd love
to code this up at some point but never took the time
to come up with a nice api.

> First of all you don't cope with the first element properly.  Then, there
> are simple and efficient solutions available.  To name some:
>
> [snip]

yeah. agreed on lack of coping with first element
i just wanted to illustrate the basic idea :)

sorry but i dislike these paradigms instensly :/
the iterator knows, so why should i have to duplicate
code like this. especially in a detect loop this
is incredibly annoying as in many cases a temporary
must be used for the returned value as the last statement
in the loop has to be "old_value = current_value".
also having a temporary outside the loop and polluting
the outer block... is disgusts me... maybe i'm just too 
purist but stuff like this *could* be solved so i 
see no reason against doing it :)

thanks for the feedback,
Alex