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