On Wednesday, 2 July 2014 at 17:21:36 UTC, Jonathan M Davis via
Digitalmars-d wrote:
By not putting these functions on Object, it allows them to
have whatever
attributes they need when declared in derived types. Without
that, we're stuck
That's not the problem of the Object class, that's the problem of
D syntax that doesn't allow to override a "normal" method with
"const" method of the same signature. Whenever the body of the
method touches argument's internals or not, whenever the result
type is immutable or not, is the implementation detail, not part
of the signature and should not prevent the method from being
overridden. Removing basic operations from the root of the class
hierarchy can cripple the whole OO model of D.
with whatever attributes are on the one in Object, which is
unacceptably
restrictive. The _only_ thing we lose here is the ability to
call any of these
functions on Object directly, which arguably is no real loss.
- Jonathan M Davis
Look at this from this point: a programmer new to D, writes his
first class. Then he tries to sort a collection/array of such
newborn objects, and - apparently - gets a compiler error because
"your class doesn't define opCmp". He wants to fix that by adding
the method. Question: where should he read about what opCmp is,
what arguments it takes, what value returns, and the most
important, what basic rules it should comply with? If these
things aren't defined in Object anymore, where they should be
defined instead? If there is no easy access to opCmp's contract,
what the chances are that the method will be written correctly?
