On Mon, Jun 7, 2010 at 1:10 PM, Rein Henrichs <reinh / reinh.com> 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 <dblack / rubypal.com>:
>>>
>>>> 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"?    >>> 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.

I really should turn this into a blog article I guess.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale