A fresh look at comparisons

[Scott S. McCoy]

On Mon, 2008-04-14 at 19:41 +0100, Janice Caron wrote:
> 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?

Another programming language.

What I mean is this, you have an expression which appears just as any
other expression, but it is not evaluated as is instead "special
syntax".  This is relatively disconcerting.  In fact, you double that by
adding another operator which is often used for all-too-many other
things ("is") in your examples.


> I agree.

Yay!

> >  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).

But you're making assumptions about the application's definition of
equality.  See, that's the point of having opEquals overloadable: So the
application can define equality.  And these assumptions may very well
not be safe.  Can you say definitively and for certain that in all
environments in all programs ever written in D, that an object of type A
and an object of type B will never be equal even though they have no
common ancestor?

Certainly not.

And also, we cannot say that for instance, if you have types B and C
which are both descendants of type A, that you will want B to be equal
to C if A.opEquals() returns true for the two instances.

Naturally, we could, but it would be a potentially unsafe assumption
which would reduce the possible usability of the language in some cases,
for instance when an object has a factory method to translate itself to
another type, which existed prior to it and is not an ancestor because
the target type is a part of an inheritance tree which is otherwise
irrelevant for the implementation of the source type....if that makes
any sense.  However when calling opEquals on the source type, it may
want to be equal to the instance of the target type, assuming the
planets are aligned.  It'd take me a bit of creativity to come up with a
good example, but I'm sure I could.

Cheers,
	Scott S. McCoy