Getting the const-correctness of Object sorted once and for all

[Chad J]

On 05/15/2012 06:41 PM, Chris Cain wrote:
> On Tuesday, 15 May 2012 at 21:18:11 UTC, Chad J wrote:
>> On 05/15/2012 03:32 PM, Chris Cain wrote:
>>> On Tuesday, 15 May 2012 at 18:07:12 UTC, Chad J wrote:
>>>> An idea I thought of is to introduce a method local declaration that
>>>> allows a method to access instance-specific-state that isn't
>>>> accessible to the rest of the class:
>>>
>>> This is an interesting idea (as it seems to really try to keep
>>> the state changes internal to the function, which can be seen as
>>> how D handles purity)... however, it breaks the point of purity due to
>>> this:
>>>
>>> pure nothrow hash_t toHash() const {
>>> @instance hash_t bad = 0;
>>> ++bad;
>>> return hashfn(field) + bad;
>>> }
>>>
>>> Now it violates everyone's definition of purity and we can no
>>> longer make our sweet optimizations and reasoning about the code.
>>> Sure, we could "trust the programmers to not do this" ... but
>>> that's another debate entirely.
>>
>>
>> Yes. I intend to "trust the programmers to not do this".
>>
>> Otherwise we need to find some way to ensure that a function that
>> alters external state will always return the same value as long as the
>> rest of the program doesn't change the state it looks at.
>
> It still wouldn't work though. Your @instance variables couldn't
> be stored with the object (and, thus, would have to be a pointer
> to mutable memory). So it'd require some backend work to make
> sure that's even feasible (it is, you could have an immutable
> pointer to a mutable pointer to the int, but let's face it:
> that's further spitting in the face of the way D's type system
> has been designed).
>
> So, you'd have invisible indirections, additional complexity, and
> you'd have to trust the programmers to be responsible. In other
> words, C++ + the slowness of indirections.
>

The idea /was/ to store the @instance variable with the object 
specifically to avoid complex indirections.  Still have to trust 
programmers though :/

Otherwise it's better to just memoize things using external lookups and 
whatnot.  That solution does have complex indirections, but it doesn't 
require trusting the programmer and it exists already.

> On Tuesday, 15 May 2012 at 22:33:56 UTC, Era Scarecrow wrote:
>> Perhaps an alternate workaround... a thought coming to mind, is that
>> the constructor for a const object lets you set it once in the
>> constructor (but not touch it again after) So.... Maybe...?
>
> This is a good approach, but I think a lot of people want something
> that's lazy ... if they don't need a hash, they don't want it to be
> calculated for them.
>
>
> FWIW, my idea: the thing we really need to do is to R&D some
> design patterns & idioms for D. There's solutions for using const
> and caching and such, but formalizing them and working out the
> kinks to make sure it's optimal for everyone's circumstances
> would be helpful. And people will have to accept that C++'s
> particular idioms can't be used with D (and vice versa ... some
> things you can do easily in D is infeasible or incorrect/invalid
> with C++).
>
> Book idea? :) I'd do it, but I'm just a student, so I haven't
> seen even a decent subset of all possible software engineering
> problems.
>