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
