Aggregates & associations

[Sean Kelly]

Bruce Adams wrote:
> On Wed, 19 Dec 2007 15:11:46 -0000, Jason House 
> <jason.james.house at gmail.com> wrote:
> 
>> Steven Schveighoffer Wrote:
>>
>>> "Sean Kelly" wrote
>>> >A long time ago Walter mentioned that the "scope" attribute may be 
>>> extended
>>> >to indicate aggregation:
>>> >
>>> >     class Foo
>>> >     {
>>> >         Bar valA;
>>> >         scope Baz val2;
>>> >     }
>>> >
>>> > With the above, the size of Foo would be expanded to contain an 
>>> instance
>>> > of Baz and val2 would be initialized to reference this memory, very 
>>> much
>>> > like "scope" works in functions now.  But I didn't see any mention 
>>> of this
>>> > in the D 2.0 writeup so the idea may have been either discarded or
>>> > forgotten.
>>>
>>> I believe this type of behavior is not necessary.  Whether a member 
>>> is an
>>> aggregate or an association, it will be deleted when nothing 
>>> references it
>>> anymore, which is when it should be deleted.  The only thing this 
>>> proposed
>>> behavior can do is cause segfaults when something that still has a 
>>> reference
>>> to a scoped member tries to use it.
>>
>> It has more value that that.  It's easy for me to imagine a scope 
>> class that includes one or more scope classes (such as a wrapper 
>> around an RAII object)
> 
> Also failing early can be a good thing. Attempting to use an associated 
> object that
> is not valid is an error. Just because you have not released the memory 
> for it
> does not make it valid. You program could give the illusion of working 
> for a bit
> and then die mysteriously.
> The ability to delete deterministically as an optimisation could make 
> programs more
> efficient too. You might even be able to simplify collection sweeps or 
> switch them off
> temporarily without compromising performance.

Interestingly, if objects are constructed inside the memory reserved for 
other objects, then if one is collected by the GC it must be true that 
all other objects in the same block are free as well.  Also, since they 
share memory, all the objects can safely refer to one another in their 
dtors so long as they are careful to avoid using member data that may 
already have been released.  As you say, this promises to offer some 
interesting possibilities for composite objects.


Sean