David A. Black wrote:

Anyone think of a better name?

subject. I know, I know... it's not used in other languages :-) But
it's like you're subjecting this object to block treatment, or
something. Or it's the subject of your block.

array.subject({}) do |hash, element| ... end

I like keeping it in the "*ject" family.

David

I kind of like this idea, but as implemented, this method is only on Enumerator, not Enumerable, so you'd have to write array.each.subject({}). And having it only on Enumerator makes it harder to argue for a *ject name. On the other hand, knu himself made this same mistake when writing his delete_if example earlier on the thread, so maybe we can convince him to make this a general Enumerable method. (Of course, in that case, the easiest name might just be "each_with".)

I don't like subject, it reads to me more as a noun that a verb, and it doesn't invoke any connotation of what the method is doing

Meinrad Recheis wrote:

The method's semantic can be seen as "carrying" an object/value along while iterating over a sequence. Hence the name "carry" would also suit.

To avoid any confusion about what the method returns we could discuss introducing a method "carry" which returns self and a method "carry_and_return" which returns the carry.

-- henon

I could live with the name "carry", but I'm not crazy about it. As for distinguishing carry and carry_and_return, that is like my proposal for "adding" and "returning". The thing I'm not clear about is whether it is useful for carry (or adding) to return self when self is an Enumerator rather than the original enumerable object. Returning an array is one thing, but returning the enumerator object returned by array.each is another, and I haven't convinced myself that there are instances where this would be useful. Again, this would be different if the method were on Enumerable instead of Enumerable::Enumerator.

knu: could you explain your thinking in putting this method on Enumerator instead of Enumerable?

As for names, if "returning" is already taken, does "using" work for anyone? Its vague, but no vaguer, I think, than with_memo. How about "passing"? Makes it very clear that the value is passed in to the block, but less clear that it is passed (returned) back.

The way returning is currently used is as a "functional" method, although it's defined (in Rails) as an instance method of Object, it's almost invariablly used without an explicit receiver. Its intent is to be the Ruby version of the K combinator of functional programming.

As I pointed out, this is really just an iterative variant of the K combinator, so I'm not sure that returning still isn't an appropriate name. It's not that we don't have method names in Ruby whose arguments and semantics change slightly when implemented in different classes, take for example the various subtle differences in the each method.