Why are opEquals/opCmp arguments not in or const for Objects?

[Paulo Pinto]

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