Comparing apples and oranges

Jeremie Pelletier jeremiep at gmail.com
Tue Sep 29 08:05:48 PDT 2009


Andrei Alexandrescu wrote:
> Consider:
> 
> class Apple {}
> class Orange {}
> 
> void main() {
>     writeln(new Apple == new Orange);
> }
> 
> This program always prints "false".  By and large, it is odd that one 
> would attempt comparison between unrelated classes. I was thinking, is 
> this ever legitimate, or we should just disallow it statically whenever 
> possible?
> 
> The comparison would still remain possible by casting to a parent class:
> 
>     writeln(cast(Object) new Apple == cast(Object) new Orange);
> 
> I could think of rare cases in which one would want two sibling types to 
> compare equal. Consider:
> 
> class Matrix { ... }
> // No state added, operations optimized with BLAS
> class BLASMatrix : Matrix {}
> // No state added, operations optimized with LAPACK
> class LAPACKMatrix : Matrix {}
> 
> Since neither derived class adds any state, both act in comparisons just 
> like the base class Matrix, so it's valid to compare a BLASMatrix with a 
> LAPACKMatrix.
> 
> How do you think we should go about this? Stay error-prone for the 
> benefit of a few cases, or disallow sibling class comparisons statically?
> 
> 
> Andrei
> 

You can already explicitly do "(new Apple).opEquals(new Orange);" so why 
not first resolve == to opEquals and then try to match the parameters, 
walking through all known opEquals until a matching one is found.



More information about the Digitalmars-d mailing list