From: David A. Black on
Hi --

On Mon, 7 Jun 2010, Robert Klemme wrote:

> 2010/6/7 David A. Black <dblack(a)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"? 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

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

From: Rein Henrichs on
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(a)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"? 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.

--
Rein Henrichs
http://puppetlabs.com
http://reinh.com

From: Rick DeNatale on
On Mon, Jun 7, 2010 at 1:10 PM, Rein Henrichs <reinh(a)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(a)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"?  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.

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