Inherited const when you need to mutate

[H. S. Teoh]

On Mon, Jul 09, 2012 at 08:07:22PM +0200, Timon Gehr wrote:
> On 07/09/2012 07:49 PM, Andrei Alexandrescu wrote:
> >On 7/9/12 12:34 PM, David Piepgrass wrote:
> >>I guess D does not have 'mutable' (like C++) to override const on
> >>methods?
> >
> >It doesn't, which makes life difficult for certain idioms. On the
> >upside, you can assume more than C++ does about immutable data.
> >
> >>Caching anything slow-to-compute is my typical use case, and I know
> >>a hashtable design where the getter will move whatever value at
> >>finds to the front of a hash collision chain.
> >
> >Yah, that won't be easy to implement. We have a couple of designs in
> >mind for "mutable", but didn't get to it. Regarding advantages, think
> >of this - if an immutable instance of your bring-to-front hashtable
> >were used by multiple threads it would fail because it's "lying"
> >about its being immutable. For now just don't use const for what
> >ain't.
> >
> 
> This is very inconvenient if the root of the class hierarchy uses it.
[...]

I'm wondering if it makes any sense to have _also_ have non-const
versions of things like toString, for objects that want to implement
caching. So in contexts where const is not important, you can have
caching, network access, whatever you want, but for core language stuff
that needs to assume const, everything will still work (just a little
slower).

I'm thinking of the case where some objects might be kept in ROM, say,
in which case you can't cache within the class, even if you wanted to.
But for other instances of the class that are outside ROM, you can be
free to use the non-const, caching, network-accessing version of
toString to your heart's content.

After all, we have inout for a reason; here's a case where we need to do
the opposite of inout (have both a const and non-const version of a
method).

Or am I just spouting nonsense again? ;-)


T

-- 
Help a man when he is in trouble and he will remember you when he is in trouble again.