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.