Re: Enumerable::Enumerator#with_memo

Akinori MUSHA wrote:
> At Wed, 4 Jun 2008 03:38:48 +0900,
> David Flanagan wrote:
>> Akinori MUSHA wrote:
>>> Hi,
>>>
>>> Earlier today I added a new instance method named `with_memo' to
>>> Enumerable::Enumerator, but I'm not 100% sure if the name fits the
>>> function.
>> What does the method do?  What's the use-case?

Thank you for this clarification.  This seems like a very useful (even 
if not commonly used) method you've added.
> 
> For example:
> 
>     class Array
>       def my_map
>         return with_memo([]) {|i, memo| memo << yield(i) }

I think you meant each.with_memo([]) here, right?  Or are you 
considering adding this to Enumerable instead of Enumerator?

I like Rick's suggestion of the name "returning" for this use case.

>     a = [2,5,2,1,5,3,4,2,1,0]
> 
>     # Remove element duplicates:
>     a.delete_if.with_memo({}) {|i, seen|
>       if seen.key?(i)
>         true
>       else
>         seen[i] = true
>         false
>       end
>     }
> 
>     p a  # [2, 5, 1, 3, 4, 0]
>     ## The point is `seen' is only seen in the block, and there is no
>     ## leftover variable after the operation.
>     ##
>     ## Note that you cannot easily do the equivalent job with
>     ## inject().
> 
> 
> The method is for eliminating the typical need for a local variable to
> accumulate into or look up on from within a block.

In this case, we don't need, and probably don't want the memo value to 
be returned, do we?  So how about a different method for adding a 
scratch variable without having it returned?  A natural name for this 
non-returning variant would be "with".  Though I know you've already 
expressed concern that that could conflict with a future keyword. 
"with_value" would be explicit but verbose.  "adding" would complement 
the name "returning" nicely and hint at the "add a local variable" 
meaning.  If you implement this method, it could presumably accept more 
than one argument to add more than one local variable to the iteration.

I suspect that the most common use of these methods would be with the 
basic enumerator returned by each: each.returning, each.adding.  If that 
is the case, is there a performance argument for also defining 
each_returning and each_adding on Enumerable itself?

>>                                                 And can't new methods
>> like this wait 'till the Ruby 2.0 development branch opens up?  :-)
> 
> Is there any near-future plans for that?  

I have no idea.

I must agree that it is
> important to have a policy for 1.9 that we all follow, but so long as
> ruby 1.9 is the most active development series, you can't stop
> improving it. ;)
> 

I think I've already expressed my opinion about the enough, so I'll just 
say that this sounds like a circular argument: it is the most active 
development series because no one will stop improving it!  :-)

	David