I have only just started using Ruby (and am a total noob, in case this
wasn't obvious ;-)) and was wondering if I type the following into irb
(for instance) I don't see the "include" method listed:
Array.methods
Nor do I see the "each" method listed so I assume this is by design
rather than being an omission.
Would someone be so kind as to enlighten me why this is the case?
Many thanks.
Richard
RichardSchollar wrote:
I have only just started using Ruby (and am a total noob, in case this
wasn't obvious ;-)) and was wondering if I type the following into irb
(for instance) I don't see the "include" method listed:Array.methods
You want: Array.instance_methods
(that is: not methods of the class Array object itself, but methods of
objects which are instances of class Array)
--
Posted via http://www.ruby-forum.com/\.
In addition to the previously mentioned difference between #methods and #instance_methods, #inject is actually a method on the Enumerable module, which is mixed into Array (and other classes that have #each). The Enumerable module is full of methods that can be used on "things that can enumerate themselves", like Arrays, Hashes and Sets.
--
Rein Henrichs
http://puppetlabs.com
http://reinh.com
Brian Candler wrote:
RichardSchollar wrote:
I have only just started using Ruby (and am a total noob, in case this
wasn't obvious ;-)) and was wondering if I type the following into irb
(for instance) I don't see the "include" method listed:Array.methods
You want: Array.instance_methods
(that is: not methods of the class Array object itself, but methods of
objects which are instances of class Array)
Or alternatively you could do: Array.new.methods
to create an instance, and then see what methods it has.
irb(main):001:0> Array.new.methods.grep(/inject/)
=> ["inject"]
--
Posted via http://www.ruby-forum.com/\.
Hi --
In addition to the previously mentioned difference between #methods and #instance_methods, #inject is actually a method on the Enumerable module, which is mixed into Array (and other classes that have #each). The Enumerable module is full of methods that can be used on "things that can enumerate themselves", like Arrays, Hashes and Sets.
Although a surprising (to me) number of Enumerable's instance methods
are overridden in Array:
irb(main):008:0> (Array.instance_methods(false) &
Enumerable.instance_methods).sort
=> ["collect", "count", "cycle", "drop", "drop_while", "find_index",
"first", "include?", "map", "reject", "reverse_each", "select",
"sort", "take", "take_while", "to_a", "zip"]
(That's 1.8.7 but the list is the same in 1.9.1.)
David
On Mon, 7 Jun 2010, Rein Henrichs wrote:
--
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
In irb I would use instead of Array.new in that case 
Cheers
R.
On Sun, Jun 6, 2010 at 9:53 PM, Brian Candler <b.candler@pobox.com> wrote:
irb(main):001:0> Array.new.methods.grep(/inject/)
=> ["inject"]
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.
On 2010-06-06 17:55:58 -0700, David A. Black said:
Hi --
On Mon, 7 Jun 2010, Rein Henrichs wrote:
In addition to the previously mentioned difference between #methods and
#instance_methods, #inject is actually a method on the Enumerable module,
which is mixed into Array (and other classes that have #each). The Enumerable
module is full of methods that can be used on "things that can enumerate
themselves", like Arrays, Hashes and Sets.Although a surprising (to me) number of Enumerable's instance methods
are overridden in Array:irb(main):008:0> (Array.instance_methods(false) &
Enumerable.instance_methods).sort
=> ["collect", "count", "cycle", "drop", "drop_while", "find_index",
"first", "include?", "map", "reject", "reverse_each", "select",
"sort", "take", "take_while", "to_a", "zip"](That's 1.8.7 but the list is the same in 1.9.1.)
David
--
Rein Henrichs
Thanks everyone - I appreciate all the responses and it has clarified
what I was seeing.
Hi --
On Mon, 7 Jun 2010, Rein Henrichs wrote:
On 2010-06-06 17:55:58 -0700, David A. Black said:
Hi --
On Mon, 7 Jun 2010, Rein Henrichs wrote:
In addition to the previously mentioned difference between #methods and
#instance_methods, #inject is actually a method on the Enumerable module,
which is mixed into Array (and other classes that have #each). The Enumerable
module is full of methods that can be used on "things that can enumerate
themselves", like Arrays, Hashes and Sets.Although a surprising (to me) number of Enumerable's instance methods
are overridden in Array:irb(main):008:0> (Array.instance_methods(false) &
Enumerable.instance_methods).sort
=> ["collect", "count", "cycle", "drop", "drop_while", "find_index",
"first", "include?", "map", "reject", "reverse_each", "select",
"sort", "take", "take_while", "to_a", "zip"](That's 1.8.7 but the list is the same in 1.9.1.)
David
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
--
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
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.
Kind regards
robert
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.
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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"? 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
Indeed. The Rubinius implementations of these Array methods are quite revealing. It is easy to see the difference between them and their Enumerable counterparts.
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"? 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
--
Rein Henrichs
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.
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"? 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.
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Hi --
Hi --
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
On Tue, 8 Jun 2010, Rick DeNatale wrote:
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:
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:
--
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