Congratulations to the D Team!

[Christophe Travert]

Andrei Alexandrescu , dans le message (digitalmars.D:171945), a écrit :
> On 7/11/12 1:40 PM, Jakob Ovrum wrote:
>> Some classes don't lend themselves to immutability. Let's take something
>> obvious like a class object representing a dataset in a database. How is
>> an immutable instance of such a class useful?
> 
> This is a good point. It seems we're subjecting all classes to certain 
> limitations for the benefit of a subset of those classes.

Does Object really need to implement opEquals/opHash/... ? This is what 
limits all 
classes that do not want to have the same signature for opEquals.

The problem is not only in the constness of the argument, but also in 
its purity, safety, and throwability (although the last two can be 
worked arround easily).

You can compare struct, all having different opEquals/opHash/.... You 
can put them in AA too. You could do the same for classes. Use a 
templated system, and give the opportunity for the class to provide its 
own signature ? There may be code bloat. I mean, classes will suffer 
from the same code bloat as structs. Solutions can be found reduce this 
code bloat.

Did I miss an issue that makes it mandatory for Object to implement 
opEquals and friends ?

-- 
Christophe