A fresh look at comparisons

Georg Wrede georg at nospam.org
Tue Apr 15 04:15:37 PDT 2008


Janice Caron wrote:
> On 15/04/2008, Bruce Adams <tortoise_74 at yeah.who.co.uk> wrote:
> 
>> I don't think even this is safe. The normal definition of inheritance is
> 
> Well, that's kindof the point. is(==) wouldn't /use/ inheritance. It
> wouldn't be inheritable. It's just like constructors aren't
> inheritable.
> 
> The whole point is the recognition that inheritance is not the right
> mechanism when it comes to comparisons, and hence the quest for a
> different mechanism that /is/ appropriate.

Well, that depends. If I design a class hierarchy where I want to 
compare instances, I'd either have the superclass define the comparison, 
if it's appropriate. If, OTOH, the different subclasses should compare 
differently, then of course the comparison has to be defined for them 
separately. I'm not sure I see a big problem here.

>> Yes. The semantics are there. We just need to find a syntax that
>> fits better with D. This doesn't quite sit right when everything
>> else is an Op-something.
> 
> It wouldn't be a function in the conventional sense. Choosing a syntax
> that makes it look /not/ like a function is entirely deliberate. It's
> just like constructors don't look like functions; destructors don't
> look like functions; class invariants don't look like functions; unit
> tests don't look like functions.
> 
> opAdd() is a function, subject to all the normal rules of functions,
> including inheritance, overloading, overriding, etc. They're different
> beasts, so they need to look different, syntactically.
> 
> (Also, I chose "is" so as to avoid introducing a new keyword).



More information about the Digitalmars-d mailing list