On 10/07/12 19:13, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 06:48:51PM +0200, Timon Gehr wrote:
On 07/10/2012 06:45 PM, H. S. Teoh wrote:
Yeah, this is logical const. Unfortunately, D doesn't have logical
const.
Then why on earth is druntime acting as if it does?
Y'know, this brings up an interesting question. Do methods like toString
_need_ to be const? That is, _physical_ const? Or are we unconsciously
conflating physical const with logical const here?
Yes, certain runtime operations need to be able to work with const
methods, but I wonder if those required const methods really belong to a
core set of more primitive operations that guarantee physical const, and
perhaps shouldn't be conflated with logical operations like "convert
this object to a string representation", which _may_ require caching,
etc.?
Or perhaps application code want to be defining their own non-const
versions of certain methods so that they can do whatever they need to do
with logical const, without worrying about breaking physical const-ness.
I'm starting to think that D's hardline approach to const is clashing
with the principle of information hiding. Users of a class shouldn't
_need_ to know if an object is caching the value of toString, toHash, or
whatever it is. What they care for is that the object doesn't visibly
change, that is, logical const. Binary const implies logical const, but
the implication doesn't work the other way round. While it's nice to
have binary const (strong, enforceable guarantee), it breaks
encapsulation: just because a class needs to do caching, means its
methods can't be const, and this is a visible (and viral, no less)
change in its external API. What should just be an implementation detail
has become a visible difference to the outside world -- encapsulation is
broken.
I don't know how to remedy this. It's clear that physical const does
have its value -- it's necessary to properly support immutable, allows
putting data in ROM, etc.. But it's also clear that something is missing
from the picture. Implementation details are leaking past object APIs,
caching and other abstractions can't work with const, etc., and that's
not a good thing.
T
I think you're right.
Something I wonder about, though, is how many different use cases are we
dealing with?
Suppose we had a caching solution (you could think of it as @cached, but
it could be done in a library). The user would need to provide a const,
pure function which returns the same value that is stored in the cache.
This is enforceable. The only way to write to the cache, is by calling
the function.
How far would that take us? I don't think there are many use cases for
logically pure, apart from caching, but I have very little idea about
logical const.
