Ruby Forum Ruby > Array API

Posted by Tushar Gandhi (tushar_gandhi)
on 19.08.2008 11:10
Hi,
  I am going through the ruby Array API. In the API , there is staetment

Included Modules
Enumerable

Is this means that we are inheriting the enumerable class to array?

Also there is sort_by method for the enumerable object, but I am able to
use this method for array of object.

I have this type of array of Object:-
[#<UserDemo:0x89a5bd4 @attributes={"email3"=>nil, "lastname"=>"aikhe",
"firstname"=>"mita", "id"=>"1"}>,#<UserDemo:0x89a5bd4
@attributes={"email3"=>nil, "lastname"=>"aikhe", "firstname"=>"na",
"id"=>"2"}>]

How it is possible that we are able to use enumerable sort_by method for
an array of object?

Thanks & Regards,
Tushar
Posted by Frederick Cheung (Guest)
on 19.08.2008 11:49
(Received via mailing list)
On 19 Aug 2008, at 10:06, Tushar Gandhi wrote:

> Hi,
>  I am going through the ruby Array API. In the API , there is  
> staetment
>
> Included Modules
> Enumerable
>
> Is this means that we are inheriting the enumerable class to array?
>
Not inheriting. That means the Enumerable module is mixed in to Array
(and similarly to Hash and other collections)

> How it is possible that we are able to use enumerable sort_by method  
> for
> an array of object?
>
Because that's what including a module does: it adds the methods
defined in the module to the class.

Fred
Posted by Tushar Gandhi (tushar_gandhi)
on 19.08.2008 12:18
Frederick Cheung wrote:
> On 19 Aug 2008, at 10:06, Tushar Gandhi wrote:
> 
>> Hi,
>>  I am going through the ruby Array API. In the API , there is  
>> staetment
>>
>> Included Modules
>> Enumerable
>>
>> Is this means that we are inheriting the enumerable class to array?
>>
> Not inheriting. That means the Enumerable module is mixed in to Array
> (and similarly to Hash and other collections)
> 
>> How it is possible that we are able to use enumerable sort_by method  
>> for
>> an array of object?
>>
> Because that's what including a module does: it adds the methods
> defined in the module to the class.
> 
> Fred

Hi,
  Is sort_by method will cause performance problem? or Is it faster 
sort?

Posted by Jesús Gabriel y Galán (Guest)
on 19.08.2008 14:41
(Received via mailing list)
On Tue, Aug 19, 2008 at 12:15 PM, Tushar Gandhi
<tushar_gandhi@neovasolutions.com> wrote:
> Hi,
>  Is sort_by method will cause performance problem? or Is it faster
> sort?

The theoretical performance comparison between sort and sort_by is
explained here:

http://www.ruby-doc.org/core/classes/Enumerable.html#M003151

Nevertheless, when talking about performance it's better to benchmark
yourself for your
specific case.

It basically all boils down to how expensive is to calculate the
comparison of two keys in the array,
versus the number of comparisons needed.

Jesus.
Posted by Robert Klemme (Guest)
on 19.08.2008 16:13
(Received via mailing list)
2008/8/19 Frederick Cheung <frederick.cheung@gmail.com>:
>>
> Not inheriting. That means the Enumerable module is mixed in to Array (and
> similarly to Hash and other collections)

Actually, it is a form of multiple inheritance.

irb(main):001:0> Array.ancestors
=> [Array, Enumerable, Object, Kernel]

>> an array of object?
>>
> Because that's what including a module does: it adds the methods defined in
> the module to the class.

This is only true in a very general sense, i.e. if you want to express
with this that you can invoke methods defined in a module on an
instance of a class that directly or indirectly (!) inherits the
module.

irb(main):002:0> Array.instance_method :sort_by
=> #<UnboundMethod: Array(Enumerable)#sort_by>
irb(main):003:0> Array.instance_method :size
=> #<UnboundMethod: Array#size>

Note the difference between #sort_by (defined in Enumerable) and #size
(defined in Array).

Rather the module is inserted into the lookup path (see output of
#ancestors above).  Otherwise methods from different modules could not
invoke each other via super but instead one would overwrite the other:

irb(main):004:0> class Base; def x; puts "base"; end; end
=> nil
irb(main):005:0> module A; def x;puts "mod a"; super; end; end
=> nil
irb(main):006:0> module B; def x;puts "mod b"; super; end; end
=> nil
irb(main):007:0> class D1 < Base; include A; include B; end
=> D1
irb(main):008:0> class D2 < Base; include B; include A; end
=> D2
irb(main):009:0> D1.new.x
mod b
mod a
base
=> nil
irb(main):010:0> D2.new.x
mod a
mod b
base
=> nil
irb(main):011:0> D1.ancestors
=> [D1, B, A, Base, Object, Kernel]
irb(main):012:0> D2.ancestors
=> [D2, A, B, Base, Object, Kernel]

Kind regards

robert
Posted by Frederick Cheung (Guest)
on 19.08.2008 17:16
(Received via mailing list)
On 19 Aug 2008, at 15:09, Robert Klemme wrote:
> with this that you can invoke methods defined in a module on an
>
> Rather the module is inserted into the lookup path (see output of
> #ancestors above).  Otherwise methods from different modules could not
> invoke each other via super but instead one would overwrite the other:
>

Of course. it would also mean that adding methods to a module after it
had been included wouldn't work.

Fred
Posted by Frederick Cheung (Guest)
on 19.08.2008 18:45
(Received via mailing list)
On 19 Aug 2008, at 11:15, Tushar Gandhi wrote:
> Hi,
>  Is sort_by method will cause performance problem? or Is it faster
> sort?

It's what is often known as a schwartzian transform.
Joss Susser wrote some stuff up on sort/sort_by just a few days ago: 
http://blog.hasmanythrough.com/2008/8/17/sorting-things-out

Fred