A fresh look at comparisons

[Janice Caron]

On 14/04/2008, Scott S. McCoy <tag at cpan.org> wrote:
> I like this, except for the semantic irregularities similar to Scala
> we'd be introducing by not having the operator evaluated.
I don't understand what this means. What is Scala?


> Also, if you can't cast successfully I'd think you would simply return
> false for opEquals.
>
> if o !is C, then they can't possibly be equal. ;-)

I agree.


>  The idea behind opEquals acting this way, I assume naturally, is that it
>  enables the ability for your type to know how to compare itself to
>  multiple *other* types which exist.  Somewhat similar to how you can
>  freely compare a long and an int in many cases, without ramifications or
>  need to know any bit-wise or type difference.

I'm not sure that's a real concern. To use your example, int and long
will both implicitly convert to the same common type (in this case,
long), and the == test can be made on that.

In general, if a is of type A, and b is of type B, where A != B, and
there exists a common type C into which both A and B will implicitly
cast, then we only need to concern ourselves with (cast(C)a ==
cast(C)b).