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.
So, once all of those functions are removed from Object,
derived types can
then define them with whatever attributes they want. The only
thing you lose is
the ability to compare Objects directly, which is not necessary
in D and is
arguably a bad idea anyway.
The work on this conversion hasn't been done yet, and a
transition plan will
have to be put in place to minimize code breakage, but that's
what was decided
on as the solution to the issues with const and Object's
functions.
- Jonathan M Davis
Am I right in thinking that removal of these methods from Object
will mean that it will no longer be necessary for the the
argument to be of type Object and that the need for casting in
the implementation will go away?
Peter
