[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Making == symmetric?

Zach Dennis

10/1/2003 6:46:00 PM

I don't even know if I've been using Ruby long enough( the past few days )
to even comment, so I'll keep my opinions brief.

In regards to what Mark Wilson said about Sean O'Dells comments:

>I don't know enough to have firm views on the topic, but I do have a
>couple of thoughts.
>
>1. Sometimes, one will want two objects of the same class and with the
>same attributes to return false when the == operator is applied. For
>example, a pool of identical server objects should not be considered
>equal to each other.
>
>2. In general, two objects of different classes should return false
>when the == operator is applied to either of them, unless the classes
>differ only in name. I think whether this behavior is varied in
>specific cases would depend on how the class is meant to be used.

on #1. I agree with Mark and I'd also like to say...why would you want
to use the == to return true when comparing different objects, even if
they are of the same class, with the same attributes. Unless one's a pointer
or reference and you are using an equivalency of a === test. I don't see why
someone would want this expected behavior from == itself.

on #2. I think 2 different classes should always return false when compared
to
one another. Otherwise you are getting away from the simplicity and purpose
of a comparison in it's most generic form and you are bringing
in special cases where "behavior is varied". If you want to allow for
special case scenario's then perhaps make a new comparison operator/method
and leave == alone.

I way even be off with my whole post, if I am just tell me to hush up. =)

-Zach
2 Answers

Joel VanderWerf

10/1/2003 7:03:00 PM

0

Zach Dennis wrote:
...
> on #1. I agree with Mark and I'd also like to say...why would you want
> to use the == to return true when comparing different objects, even if
> they are of the same class, with the same attributes. Unless one's a pointer
> or reference and you are using an equivalency of a === test. I don't see why
> someone would want this expected behavior from == itself.

Well, for example:

irb(main):001:0> [1,2] == [1,2]
=> true

Also, strings.

Of course, this isn't really a "class with attributes", but even for
user defined classes, I sometimes define #== to work this way. This
seems like the right thing to do for geometrical objects, like points. YMMV.

>
> on #2. I think 2 different classes should always return false when compared
> to
> one another. Otherwise you are getting away from the simplicity and purpose
> of a comparison in it's most generic form and you are bringing
> in special cases where "behavior is varied". If you want to allow for
> special case scenario's then perhaps make a new comparison operator/method
> and leave == alone.

irb(main):002:0> 1.0 == 1
=> true

Or, if you had two Point classes, one maintaining its state in polar
coordinates, and the other in cartesian coordinates, you might want
equality to transcend class boundaries.

elbows

10/2/2003 5:56:00 AM

0

"Zach Dennis" <zdennis@mktec.com> wrote in message news:<AKEKIKLMCFIHPEAHKAAIMEFDGKAA.zdennis@mktec.com>...
> I don't even know if I've been using Ruby long enough( the past few days )
> to even comment, so I'll keep my opinions brief.
>
> In regards to what Mark Wilson said about Sean O'Dells comments:
>
> >I don't know enough to have firm views on the topic, but I do have a
> >couple of thoughts.
> >
> >1. Sometimes, one will want two objects of the same class and with the
> >same attributes to return false when the == operator is applied. For
> >example, a pool of identical server objects should not be considered
> >equal to each other.
> >
> >2. In general, two objects of different classes should return false
> >when the == operator is applied to either of them, unless the classes
> >differ only in name. I think whether this behavior is varied in
> >specific cases would depend on how the class is meant to be used.
>
> on #1. I agree with Mark and I'd also like to say...why would you want
> to use the == to return true when comparing different objects, even if
> they are of the same class, with the same attributes. Unless one's a pointer
> or reference and you are using an equivalency of a === test. I don't see why
> someone would want this expected behavior from == itself.

> on #2. I think 2 different classes should always return false when compared
> to
> one another. Otherwise you are getting away from the simplicity and purpose
> of a comparison in it's most generic form and you are bringing
> in special cases where "behavior is varied". If you want to allow for
> special case scenario's then perhaps make a new comparison operator/method
> and leave == alone.

If you just want to find out whether two references point to the same
object, that's what the equal? method is for. It's defined in Object
and explicitly not meant to be overriden.

==, on the other hand, is supposed to be used for richer comparisons,
and subclasses are free to override it. In fact, == is already
overridden by several classes in the standard libraries, like String
and Array.

Nathan