From: David A. Black on 7 Jun 2010 09:08 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 7 Jun 2010 13:06 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 7 Jun 2010 15:25 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
First
|
Prev
|
Pages: 1 2 3 Prev: libruby-nntp doesn't exist any more ? Next: Singleton classes and Namespce |