Possible way to achieve lazy loading with const objects

[Gor Gyolchanyan]

Immutable is a guarantee, that no mutable reference can be obtained on
the object from any reference (I don't take into account casting it
away, because that's not guaranteed to make the object actually
mutable).
Const is a guarantee that, no mutable reference can be obtained from
this particular reference reference.
The key difference is, that const implies the general mutability of
the object, which is not accessib
Const actually is a logical const. Immutable, on the other hand, is a
physical const.
I'm not sure if const-defined objects are potentially stored in ROM
(in contrast with immutable-defined ones), but if it is, then it
shouldn't be, since ROM is purely immutable's domain.
Const should in fact be transitive, because if you can change
something, you can't change it's part either.
Another question is, that casting away const should be 100% defined
behavior and result in 100% valid mutable reference, in contrast to
immutable.
Some classes, for example, may be designed to mutate due to some
caching, reference counting or similar mandatory-mutable stuff.
In which case the class should be able to obtain a mutable reference on itself.
Immutable classes, however should not be able to, because
synchronization depends on physical immutability of the data.
In light of that, one should be able to define specializations of
classes based on their mutability level (kind of class overloading):

class MyCachingClass
{
/// No const or immutabe shenanigans.
/// The class itself is mutable.
}

const class MyCachingClass
{
/// Some minor internal tricks with const.
/// The class itself is const.
}

immutable class MyCachingClass
{
/// No caching, no reference counting.
/// The class itself is completely immutable to anyone.
}

void main()
{
    auto mcc1 = new MyCachingClass;
    auto mcc2 = new const(MyCachingClass);
    auto mcc3 = new immutable(MyCachingClass);
}

The whole point of having const and immutable simultaneously is
because const is purely logical and immutable is physical.
And const's logic can be changed when necessary, while immutable's cannot.

Cheers,
Gor.

On Thu, Sep 29, 2011 at 12:12 PM, Peter Alexander
<peter.alexander.au at gmail.com> wrote:
> On 29/09/11 8:13 AM, Marco Leise wrote:
>>
>> Am 26.09.2011, 18:12 Uhr, schrieb Jonathan M Davis <jmdavisProg at gmx.com>:
>>
>>> On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote:
>>>>
>>>> For example, storing a reference to a mutex in an object, or a reference
>>>> to an owner object. It's the difference between a "has a" relationship
>>>> and a "points to" relationship.
>>>>
>>>> Your lazy loading idea does not help at all for these.
>>>
>>> I believe that the two main complaints about the lack of logical const
>>> which
>>> have been coming up in the newsgroup have been the inability to cache the
>>> return values of member functions and the inability to lazily load the
>>> values of member variables.
>>
>> I brought the issue with "points to" relationships up in another thread
>> here - also about transitive const. I believe a proper object-oriented
>> design should allow for pointers to other objects that have nothing in
>> common with the host object. car.getVendor() for example should always
>> return the mutable instance of the shop where that - possibly const car
>> - was bought. Let's call it the "parent reference" issue for short :)
>> +1 to Steven's comment.
>
> Why would a car be able mutate it's vendor?
>
> Also, the problem with mutable parent references is that it completely
> defeats the purpose of const. Consider this C++ code:
>
> struct Tree
> {
>    Tree* m_parent;
>    std::vector<Tree> m_children;
>
>    void doSomethingConst() const;
> };
>
> The tree owns it's children, and has a mutable reference back to its parent.
>
> Inside doSomethingConst, I shouldn't be able to modify my children because I
> own them, however, you are arguing that I should be able to get a mutable
> reference to my parent. However, if I can get a mutable reference to my
> parent, then I can get mutable references to its children, of which (this)
> is one. So, through my parent I can get a mutable reference to myself,
> circumventing the const, making it pointless.
>
> Strict transitive const is essential. Without it, it becomes far too easily
> to wriggle your way out of const, which breaks the guarantees of immutable.
>
>