Inject method of Array class

Ruby
1

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

2

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)

3

Brian C. 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”]

4

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.

5

On Sun, Jun 6, 2010 at 9:53 PM, Brian C. [email protected]
wrote:

irb(main):001:0> Array.new.methods.grep(/inject/)
=> [“inject”]
In irb I would use [] instead of Array.new in that case :wink:
Cheers
R.

6

On 2010-06-06 17:55:58 -0700, David A. Black said:

Although a surprising (to me) number of Enumerable’s instance methods

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.

7

Thanks everyone - I appreciate all the responses and it has clarified
what I was seeing.

8

Hi –

On Mon, 7 Jun 2010, Rein H. 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

–
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

9

Hi –

On Mon, 7 Jun 2010, Rein H. wrote:

module is full of methods that can be used on "things that can enumerate

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

10

Hi –

On Mon, 7 Jun 2010, Robert K. wrote:

that state is kept on the list object and doesn’t require an O(n)
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

11

2010/6/7 David A. Black [email protected]:

On Mon, 7 Jun 2010, Rein H. wrote:

On 2010-06-06 17:55:58 -0700, David A. Black said:

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.

Kind regards

robert

12

On 2010-06-07 06:08:39 -0700, David A. Black said:

I suspect that the majority are overwritten for performance reasons,
second at 6 and IO having none.

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.

13

Hi –

On Tue, 8 Jun 2010, Rick DeNatale wrote:

should return if there’s no block (like Enumerable#map always
  if (!rb_block_given_p()) {
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

14

On Mon, Jun 7, 2010 at 1:10 PM, Rein H. [email protected] wrote:

On 2010-06-06 17:55:58 -0700, David A. Black said:
returning an array vs. Array#map returning its receiver). Array is
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: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale