Aggregates & associations

[Bruce Adams]

On Wed, 19 Dec 2007 20:41:58 -0000, Sean Kelly <sean at f4.ca> wrote:

> 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

Except that at present there's no way to declare that an object is  
contained in
another object except as a struct and a struct is not an object. I don't  
think
scope would do this and if it did it would be ahem beyond its scope to do  
so.