Implementing each and <=>

I have a data model and would like to let it be Enumerable. I want to
confirm if this is the way of implementing each and <=> :

def each
  @list.each { |item| yield item }
end

def <=>(other)
  @list <=> other
end

(let’s just assume that @list is an array)

Thanks.

Ruby R. schrieb:

(let’s just assume that @list is an array)

Thanks.
i would define each like this:
def each(&blk)
@list.each(&blk)
end

badboy wrote:

Ruby R. schrieb:

(let’s just assume that @list is an array)

Thanks.
i would define each like this:
def each(&blk)
@list.each(&blk)
end

okay, i forgot to mention that I was wondering whether the
easiest/cleanest way was to use a send somehow?

def each
  @list.send
end

Actually, since the ruby source is in ‘C’ one can’t check it to see
examples. I searched a lot but came up with nothing.

Thanks.

On Jan 13, 2009, at 1:08 PM, Ruby R. wrote:

I have a data model and would like to let it be Enumerable. I want to
confirm if this is the way of implementing each and <=> :

def <=>(other)
@list <=> other
end

<=> would normally apply to items in your list, not to the container
itself.

Ruby R. schrieb:

okay, i forgot to mention that I was wondering whether the
easiest/cleanest way was to use a send somehow?

def each
  @list.send
end

Actually, since the ruby source is in ‘C’ one can’t check it to see
examples. I searched a lot but came up with nothing.

Thanks.
I don’t think that using send is easier/cleaner
using @list.each(&blk) is nothing else than sending the message “each”
to @list with blk as a block parameter

On Tue, 13 Jan 2009 15:30:20 -0500, Ruby R. wrote:

I am putting in the <=> so this class might be more useful to others. I
haven’t got around to using it myself. (I have a base class
ListDataModel with minimal methods and wanted to make it as useful as
possible).

Is there sume useful comparison for comparing two different data models
with each other? If not, then don’t define <=>.

–Ken

Dave T. wrote:

On Jan 13, 2009, at 1:08 PM, Ruby R. wrote:

I have a data model and would like to let it be Enumerable. I want to
confirm if this is the way of implementing each and <=> :

def <=>(other)
@list <=> other
end

<=> would normally apply to items in your list, not to the container
itself.

That’s whats confusing me. How would i put it?

I am putting in the <=> so this class might be more useful to others. I
haven’t got around to using it myself. (I have a base class
ListDataModel with minimal methods and wanted to make it as useful as
possible).

On Tue, 13 Jan 2009 14:15:58 -0500, Ruby R. wrote:

okay, i forgot to mention that I was wondering whether the
easiest/cleanest way was to use a send somehow?

def each
  @list.send
end

No. This won’t work. Send is just a method for calling methods, and
unless you pass it a method name and all relevant arguments, it won’t
know what message to send.

Thus, you’ll be at

def each &blk
@list.send :each, &blk
end

and it’s easier to do

def each &blk
@list.each &blk
end

–Ken

Thus, you’ll be at

def each &blk
@list.send :each, &blk
end

and it’s easier to do

def each &blk
@list.each &blk
end

–Ken

thanks, (I did forget to put the :each in the lines i put)

Is there sume useful comparison for comparing two different data models
with each other? If not, then don’t define <=>.

No, not at all. Thanks again.

Ruby R. wrote:

def <=>(other)
  @list <=> other
end

Perhaps you mean something like this:

include Comparable
def <=>(other)
@list <=> other.list # or some other way to order them
end

Making your objects Comparable is distinct from making them Enumerable.

Brian C. wrote:

Ruby R. wrote:

def <=>(other)
  @list <=> other
end

Perhaps you mean something like this:

include Comparable
def <=>(other)
@list <=> other.list # or some other way to order them
end

Making your objects Comparable is distinct from making them Enumerable.
I was thinking that including Comparable would give users the ability to
sort the existing model in various ways.

I was wrong there, since it clearly is a comparison with another model.
That is not something likely. My bad. Thanks, Brian.