On Jul 11, 2012, at 12:58 AM, Don Clugston <d...@nospam.com> wrote: > 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.
Lazy loading, which I suppose is a type of caching. Use of synchronization primitives should be allowed as well. We sidestep this because the synchronized statement sidesteps const restrictions.