From: "David A. Black" Date: 2010-06-08T05:43:56+09:00 Subject: Re: inject method of Array class --1926193751-1379113894-1275943434=:2009 Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-1379113894-1275943434=:2009" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1926193751-1379113894-1275943434=:2009 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Hi -- On Tue, 8 Jun 2010, Rick DeNatale wrote: > On Mon, Jun 7, 2010 at 1:10 PM, Rein Henrichs wrote: >> On 2010-06-07 06:08:39 -0700, David A. Black said: >> >>> Hi -- >>> >>> On Mon, 7 Jun 2010, Robert Klemme wrote: >>> >>>> 2010/6/7 David A. Black : >>>> >>>>> On Mon, 7 Jun 2010, Rein Henrichs wrote: >>>>> >>>>>> On 2010-06-06 17:55:58 -0700, David A. Black said: >>>> >>>>>> I suspect that the majority are overwritten for performance reasons, >>>>>> although some of them surprise me as well. >>>>>> >>>>>> A linked list, for instance, would have a constant time #count because >>>>>> that state is kept on the list object and doesn't require an O(n) >>>>>> enumeration of the members. >>>>> >>>>> I think it's a mixture of performance reasons and things like what it >>>>> should return if there's no block (like Enumerable#map always >>>>> returning an array vs. Array#map returning its receiver). Array is >>>>> definitely the one that has the most overrides, with Hash coming in >>>>> second at 6 and IO having none. >>>> >>>> David, I guess you meant to write "... vs. Array#map! returning its >>>> receiver"? �Note the exclamation mark. �Array#map returns a new Array >>>> on every invocation. >>> >>> I really meant to say a copy of its receiver -- I was looking at this: >>> >>> � � if (!rb_block_given_p()) { >>> � � � � return rb_ary_new4(RARRAY(ary)->len, RARRAY(ary)->ptr); >>> � � } >>> >>> from array.c. >>> >>> >>> David >> >> Indeed. The Rubinius implementations of these Array methods are quite >> revealing. It is easy to see the difference between them and their >> Enumerable counterparts. > > None of this is surprising to me as an old Smalltalker. Parts of the > Ruby implementation take the same view of inheritance and overriding > as in Smalltalk, inheritance is simply a convenient technique for the > implementation of behavior, not for building formal hierarchies. "Surprising" might be a misleading way to put it. There's definitely nothing mystifying about it, in the long run -- it's just interesting to see how it plays out. There's a quote from Matz that I've always liked, along the lines you're sketching out: I feel you're relying too much on inheritance hierarchy. In Ruby, it's at best implementation sharing. The Enumerable/Array relation is a bit different though -- not just because, strictly speaking, it isn't about inheritance, but because it's about *not* sharing implementation. It's more that Enumerable presents a kind of ideal which Array ends up achieving, even though Enumerable itself is only partially relevant. David -- David A. Black, Senior Developer, Cyrus Innovation Inc. THE Ruby training with Black/Brown/McAnally COMPLEAT Coming to Chicago area, June 18-19, 2010! RUBYIST http://www.compleatrubyist.com --1926193751-1379113894-1275943434=:2009-- --1926193751-1379113894-1275943434=:2009--