Re: memory management in Ada: tedious without GC?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 19 May 2008 15:18:48 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Sun, 18 May 2008 20:50:48 -0700 (PDT), Matthew Heaney wrote:
>> 
>>> On May 16, 4:42 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>>>> In Ada RAII is realized with controlled types. They are severely
>>>> broken in that they are intrusive in the type hierarchy and they burn
>>>> the whole budget for implementation inheritance,
>>> No, this is wrong.  You can add in Controlled-ness as far down the
>>> hierarchy as you like, by adding a controlled component.
>> 
>> This is broken too:
>> 
>> 1. You don't know exactly the order in which the Finalize of the controlled
>> component gets called.  So if you access the container object over an
>> access discriminant, that might be already invalid.
> 
> When you design a type T, should the aspects of "death"
> of an object affect the "live" aspects of T objects at all?
> Death happens at a defined moment. What happens at this
> moment is conceptually separate from what happens while
> the object is alive, even though there are relations
> between births, lives, and deaths, of course.

When an object is constructed by a public or private composition of other
objects, that breaks this separation. The life span of a component is
longer than of the record it contains. (Exactly same problem arise upon
inheritance.) Thus a component exists before the official birth and after
the death of the whole. The problem is no different from dispatching upon
construction/destruction.

The only solution is to split construction/destruction into multiple
stages, introducing class-wide constructors/destructors. Class here is
"Root_Record_Component_Type'Class."  So when, say, T is put into a record
R, then T inherits from Root_Record_Component_Type and can attach some hook
onto the constructor of the class. That constructor is a part of the
constructor of R'Class. This code will be called after construction of all
components of R and also after construction of R.

In short, T constructed as itself and T constructed as a component of
something else are not equivalent. The latter is more than the former.

> But why lump together these two aspects of dynamics in the
> same type?

Because these are two aspects of the same thing.

> Why not have types, task types perhaps, that take care
> of the post mortem affairs of related types? (Other than
> wasting the bits maybe.)

Why switching context before running a constructor should change anything?
The contradiction to the life span exists independently on that.

> We have Factories. Why not have Incineration_Plants or
> similar, with well defined protocols?
> I certainly find it strange having to think of the
> topological orderings of cleanup work when I focus on
> what objects of a type should actually do (to do ==>
> still alive).

Because these are issues are of the types algebra you have to use in order
to construct the type of the object. If you want that algebra, i.e.
records, arrays, access types construction primitives, then you have to
face the problem.

Object doing things is miles beneath that abstraction level. It's not even
typed. Types operate sets of objects. Algebra of types operates sets of
types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de