On Monday, 18 March 2013 at 01:05:25 UTC, Jonathan M Davis wrote:
On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
Why would some class want to implement these methods in a way
that alters
the object?
Because const in D is physical const, not logical const. So,
for instance,
const prevents caching. And it's quite possible that a type
which really cared
about efficiency would cache the calculated value for toHash.
Make toHash const
would make that impossible. Another possible problem would be
lazy
initialization. If opEquals is const, then lazy initialization
becomes
impossible.
We've discussed this on a number of occasions, and it's clear
that forcing
these functions to be const is a major problem, and yet they do
need to be
const for them to work with const objects. What was finally
decided during the
last big discussion on this a few months back was that we would
remove
opEqulas, opCmp, toHash, and toString from Object. They don't
need to be
there. As long as everything in the runtime which deals with
them is
templated, then there's no technical reason why Object would
need them. D
isn't Java where we have containers of Object or anything like
that. Putting
them on Object just restricts us.
Even on Java's case and as extent .NET they aren't strictly
necessary.
Nowadays I would say it was a bad design decision and the best
way would have been to have created interfaces for those
operations. The only benefit would be default implementations.
But I imagine the language designers, like everyone else, had to
build their knowledge about classes vs interfaces, and many other
OO abstractions, so what now seems wrong was seen as right at the
time.
I remember thinking Object was an evolution over C++ way of doing
things.
--
Paulo
