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

Hi,

In message "Re: [ruby-cvs:33755] Ruby:r26540 (trunk): * enum.c (enum_each_entry): new method #each_entry to pack values"
    on Sat, 06 Feb 2010 19:27:00 +0900, "Akinori MUSHA" <[e-mail]> writes:

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

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.

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

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

This is my mistake.  It should check each_entry as you've pointed
out.

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

							matz.