Transitive const sucks (ownership - aggregation v association)

[Sean Kelly]

Bruce Adams wrote:
> James Dennett Wrote:
> 
>> Walter Bright wrote:
>>> Janice Caron wrote:
>>>> It's a solution which doesn't scale.
>>>>
>>>> And there goes encapsulation...
>>> At least for this example, the same issue exists when attempting to do
>>> "const-correctness" in C++.
>> No, it doesn't.  C++ doesn't hide the references from you
>> with its syntax, but the const Rectangle having a reference
>> to a Raster would *not* imply constness of that Raster in
>> C++.  (Indeed, this is a fairly common situation, whether
>> Raster is held by reference or some kind of pointer.)
> 
> This is a good point to emphasise. In object oriented programming
> there is a clear difference between encapsulating something in an
> aggregate and merely being associated with it. In the rectangle example a raster is clearly not "part of" a rectangle but
> it is associated. 
> 
> An important concept here is ownership. In C++ I general find myself labelling pointers as owned and not-owned.
> If you own a pointer you are responsible for deleting the object it points to. Some experimental static analysis tools are able to use pointers labelled this way to reason about memory allocation. Research
> suggests (I will have to google around a bit before I can quote references) that adding something to a language to indicate ownership is warranted.


> D with its garbage collection doesn't have this problem on the surface but there is still a distinction between something that is owned and something that is referred to. This is a distinction that is (as far as I can tell) currently impossible to represent except via comments. In D everything is a reference. Perhaps the solution is to make non-owned members (in the sense of association) pointers and reserve references (minus the pointer) for aggregation. A value keyword might help some but I think it would address the wrong problem.
> 
>  For members of an aggregate const should be transitive. If I cannot change this object then I should not be able to change any of its parts.
> If there is a logger, cache or raster - Associated - with the class I may still be able to change it - depending on whether that particular associated is marked as const.

For what it's worth, I think object ownership could be communicated via 
the 'scope' keyword.  Walter mentioned in the past that he'd considered 
allowing it in class scope anyway.


Sean