Ok with the [1,2] == [1,2]. Point taken, I'm thinking on this before
i say something stupid.

But on the Polar Points and the Cartesian Points, wouldn't
you want them to inherit from the Point class and allow the
Point class to handle conversions, translations of it's
instantiated objects? Why would you want == to handle the
translation/conversion from Polar to Cartesian. Shouldn't the
class Point handle that itself outside of equality comparion.

Why have 2 Point classes? Why not just have 1 that has 2 methods:

convertToCartesian
convertToPolar

and then check for equality.

Zach




From: Joel VanderWerf [mailto:vjoel / PATH.Berkeley.EDU]

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.