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

At Tue, 2 Feb 2010 17:54:56 +0900 (JST),
matz wrote:
> matz	2010-02-02 17:54:52 +0900 (Tue, 02 Feb 2010)
>
>   New Revision: 26540
>
>   http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=26540
>
>   Log:
>     * enum.c (enum_each_entry): new method #each_entry to pack values
>       from yield into an array.

Was the name discussed somewhere?  I think it is a bad name that can
easily cause a name clash.  For example, a blog object may have
each_entry besides each_category and each_author, etc..  Alternatively
"each_tuple" might fit, but we need some more research and
consideration.

>     * 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.

>     * lib/set.rb: replace is_a?(Enumerable) with respond_to?(:each)
>       for duck typing.

This would hardly qualify as duck typing.  Why check for each when you
are to call each_entry?


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.

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