All right, all right! Interim decision regarding qualified Object methods

Christophe Travert travert at phare.normalesup.org
Thu Jul 12 01:16:19 PDT 2012


Timon Gehr , dans le message (digitalmars.D:172014), a écrit :
> Thank you for taking the time.
> 
> Removing the default methods completely is actually a lot better than 
> making inheriting from Object optional or tweaking const beyond 
> recognition and/or usefulness.
> I was afraid to suggest this because it breaks all code that assumes
> that the methods are present in object (most code?), but I think it is
> a great way to go forward.

It's not worse thant breaking all code that overrides opEqual by 
changing it's signature.

> Regarding toString, getting rid of it would imply that the default way
> of creating a textual representation of an object would no longer be
> part of Object, paving the way for the proposal that uses buffers and
> scope delegates - this will be purely a library thing.

I agree. toString should be a purely library solution. The standard 
library could easily use templates trying to use different ways to print 
the the object, depending on what methods are implemented for that 
object: direct conversion to string/wstring/dstring, a standard method 
using delegates, etc.

> Regarding backwards-compatibility, an issue that is trivial to fix is
> the invalidation of 'override' declarations in the child classes.
> They can be allowed with the -d switch for those methods. And if they
> use 'super', the compiler could magically provide the current default
> implementations.

Magic is not good for langage consistency. I would rather do a different 
fix:

Introduce a class in the standard library that is like the current 
Object. To correct broken code, make all classes inheriting from Objet 
inherit from this new class, and rewrite opEqual/opCmp to take this new 
class as an argument instead of Object. This can be done automatically.

People may not want to use that fix, but in that case, we don't have to 
implement a magical behavior with super. What can be used is 
deprecation: if I someone uses super.opEqual (meaning Object.opEqual), 
and others, he should bet a warning saying it's deprectated, with 
explanations on how to solve the issue.

A possible course of action is this:
 - revert changes in Object (with renewed apologies to people having 
worked on that)
 - introduce a class implementing basic Hashes functions with the 
current signatures. (A class with the new signatures could be provided 
too, making use of the late work on Object, which would not be 
completely wasted after all)
 - introduce a deprecation warning on uses of Object.opEqual and 
friends, informing the programmer about the possibility to derive from 
the new class to solve the issue.
 - in the mean time, make the necessary changes to enable classes not to 
have those methods (like structs)
 - after the deprecation period, remove Object.opEqual and friends.


More information about the Digitalmars-d mailing list