A fresh look at comparisons

[Janice Caron]

On 16/04/2008, Bruce Adams <tortoise_74 at yeah.who.co.uk> wrote:
>  class A;
>  class B: A;
>  class C: A;
>
>  B == C   // should not compile - unless user defined

I assume you meant

    b == c

where b is an instance of B, and c is an instance of C.

Then you should be supporting my proposal, since that's exactly what it offers.

The /current/ mechanism will allow that to compile, and

    b == c

will be transformed into

   b.opEquals(c)

which will call the function A.opEquals(Object o) with this aliased to
a, and o aliased to b. So, what you're basically saying is THE SAME AS
I - which is that inheritance is the wrong mechanism for comparisons.
We need to stop inheritance from applying to comparisons.

That was only part of my proposal, of course. Other features included:
(*) a default equality test for objects of identical type
(*) that by default, an equality test accept a parameter of the same
type as "this", not Object

and some other cunning stuff about opCmp.

If the only thing you're disagreeing about is the syntax, then as far
as I'm concerned, we're agreeing, because the syntax isn't precious to
me.


> Constructors and destructors are special kinds of function
> but they are still functions.

Constructors don't inherit. They are also called indirectly. That is,
you never call

    A a = gc.alloc(...);
    a.this(...)

Instead, you do

    A a = new A(...)

which (1) gets some memory from the gc, and then (2) calls the
constructor. So yes, it's a "special kind of function but still a
function". I'm saying comparisons should also be considered as a
"special kind of function but still a function".