Inherited const when you need to mutate

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Jul 10 14:19:46 PDT 2012


On Tue, Jul 10, 2012 at 04:11:05PM -0400, Jonathan M Davis wrote:
> On Tuesday, July 10, 2012 12:00:59 H. S. Teoh wrote:
> > I think hidden somewhere in this is an unconscious conflation of
> > physical const with logical const.
> 
> I completely disagree at least as far as classes go. opEquals, opCmp,
> toString, and toHash must be _physically_ const, because they must
> work with physically const objects.
[...]

Yes, this is because D only has physical const.

But physical const breaks encapsulation, and precludes a variety of
applications such as caching, objects accessed over the network, etc.. I
think that's what this uproar is all about. Physical const is useful,
and in many cases necessary, but I think we're deceiving ourselves if we
imagine that physical const is the whole story.

With the current state of affairs, the scope of const is greatly
limited. If I want objects which cache hash values, I'm out of luck, I
have to write my own non-const methods. If I want objects accessed over
the network, I'm out of luck, I can't use const. If I'm writing a base
class that _might_ have _one_ derived class that requires a non-const
version of a method, I'm out of luck, I can't use const at all. If my
class could conceivably be inherited by third party code, then I can't
use const -- because otherwise I might preclude my customers from
writing code that caches values.

And when I can't use const, I have to write my own version of opEquals
(and call it something else), my own convention for computing hash
values, my own version of everything in druntime.  All that elaborate
infrastructure in druntime becomes practically worthless.  It's
all-or-nothing. If I'm OK with physical const, then all is fine and
dandy.  But as soon as one thing can't be const, I've to re-engineer my
entire framework from ground up.

Isn't there something we can do to improve this situation?


T

-- 
Sometimes the best solution to morale problems is just to fire all of the unhappy people. -- despair.com


More information about the Digitalmars-d mailing list