September 13, 2007
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.)
> 

[snip]
> 
> -- James

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.

Regards,

Bruce.

September 13, 2007
Walter Bright wrote: well, quite a lot, really.


It seems that you're concentrating heavily on const for objects being able to ensure thread safety and do a number of other optimizations. Basically, as far as the owner of a const reference is concerned, the object and all its methods are 'pure'.

So, since, for all functions that can be optimized similarly and whose thread safety can be ensured similarly, we will be adding the pure keyword, why not use the pure keyword here?

Then a const reference to an object could be a weaker contract that allows everything that people have been wishing the new new const would allow, if we can find a solution for it that enough people find useable. (And by 'we' I mean 'you'.)
September 13, 2007
Christopher Wright wrote:
> Walter Bright wrote: well, quite a lot, really.
> 
> 
> It seems that you're concentrating heavily on const for objects being able to ensure thread safety and do a number of other optimizations. Basically, as far as the owner of a const reference is concerned, the object and all its methods are 'pure'.
> 
> So, since, for all functions that can be optimized similarly and whose thread safety can be ensured similarly, we will be adding the pure keyword, why not use the pure keyword here?

Now there's an idea.  I like it.


Sean
September 13, 2007
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
September 14, 2007
Walter Bright wrote:
> James Dennett wrote:
>> Walter Bright wrote:
>>> You cannot paste const on at the top level,
>>> it has to be put in at every level underneath it.
>>
>> I'm not sure what you mean by that.  There's not much context in which to interpret it.
> 
> 
> Try turning a char* into a const char* at the top level of your program where you don't use const anywhere else. You'll have to add it to every function that takes that variable as an argument, then recursively add it to every function that one calls.

OK, now I understand: and what you say is true, const-correctness can't trivially be layered on top of const-ignorant ccode unless you tolerate a boundary layer with const_cast where needed.  That's a good thing and a bad thing -- good in that it puts pressure on the lower layers to "do the right thing", bad in that it makes it harder for higher layers to do so if the layers beneath do not.

However: for most C++, 99% of the time, it's not a problem.

-- James
September 14, 2007
Walter Bright wrote:
> James Dennett wrote:
>> Walter Bright wrote:
>>
>>> Or you can cast away const-ness. But you are on your own if you do that.
>>
>> Well, in C++ you'd be fine, but in D I thought the behavior
>> if you modified something after casting away const was
>> undefined, so you're out of luck.  (Not that you'd need
>> to cast away const for this in C++.)
> 
> It's also undefined behavior if you cast a pointer to an int. You need to know what you're doing.

Right.  But you've snipped too much context.  The point was that C++ allows something, and D doesn't.  In D you can't even cast away the const and then modify the underlying object, because it's undefined (so if you do so, you *don't* know what you're doing).

The need is to modify state in an object associated with another
object.  That doesn't change the object in question (either
physically or logically) but is disallowed by D, as there's
no recognition that association does not imply aggregation/
containment.

-- James
1 2 3 4 5 6 7 8
Next ›   Last »