[ruby-core:28088] Re: [ruby-cvs:33755] Ruby:r26540 (trunk): * enum.c (enum_each_entry): new method #each_entry to pack values

At Sat, 6 Feb 2010 22:18:12 +0900,
matz wrote:
> The name #each_entry corresponds to the existing method #entries.
> enum.each_entry works just like enum.entries.each without array
> allocation.  I think this is a good rationale.  In contrast, tuple is
> a new name and concept to Enumerable and even Ruby.

I don't think #entries is a good name by now either, since we only use
the term "item" and "element" in our documents to indicate stuff that
comes out of an iterator.  The historical name #entries never became
much of a problem just because there was #to_a, the obvious and much
more popular alternative.  However, extending the use of "entry" at
this stage seemed like a submarine rising to me, making me feel
worried about name clashes against today's existing code.

On second thought, it may be a needless worry because "entries" sound
like, among others (such as "categories" and "authors" in my "blog"
example) the most likely items an object would provide via each(),
which means each_entry() would likely be an alias for each().  Given
those assumptions, so long as each yielded "entry" is an s-value there
would be no problem to use "each_entry" for the purpose you intend.

In any case, running through these thoughts would be nice to take
place.  It's just my two yen.

> |>     * lib/set.rb (Set#merge): use Enumerable#each_entry to implement
> |>       Set compatible to 1.8 behavior.  [ruby-core:27985]
> |
> |It is high time for programmers to face the fact that yielding
> |multiple values and yielding an array are no longer the same after
> |1.9.  Set expects the incoming object, although not documented, to be
> |a stream of single objects.  Passing a multiple value stream shall
> |result in undefined behavior.  I would rather add such a note to the
> |documentation instead of adding a kluge.
>
> Don't call it a kludge.  After serious consideration, I thought the
> new behavior is nicer for users.  But after all, set.rb is your

Kluge might not be a good choice of word, but if you are recommending
the wide use of each_entry for a certain purpose, please make a
proposal.  It seemed to me you were in such a rush to add a new method
just to solve one problem in one library, which I, the author, didn't
even consider a bug.

> product, so I don't force you.  You can make set.rb not to use
> each_entry again (with documentation), if you don't agree with me
> here.  But I want you to leave is_a? removal.

I'm fine with that.  It was not me who put the is_a? test there, but
someone did without me noticed.  Given that, do you think a duck type
test (respond_to?) is needed when the due call follows soon?

> |If you are going to make a revamp in m-value/a-value invocation in
> |2.0, it has to be done on a firm, subtly though-tout grand design.
> |Instant solutions in the name of compatibility would spoil such an
> |opportunity and become a burden in the future.
>
> The m-value/a-value invocation was thoroughly discussed through 1.9
> development.  There will be no revamp, as far as I believe.

Okay, thanks for the clarification.

--
Akinori MUSHA / http://akinori.org/