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
