Re: Task origin track from a class

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

On Wed, 13 Jul 2011 10:43:15 +0200, Georg Bauhaus wrote:

> On 7/13/11 9:41 AM, Dmitry A. Kazakov wrote:
>> On Tue, 12 Jul 2011 17:36:29 -0700 (PDT), Shark8 wrote:
>>
>> The actual problems are:
>>
>> 1. The procedure of destruction of the objects having task components.
>> Tasks are completed *before* Finalize is called. Ada's approach to
>> construction/destruction is very much broken.
> 
> When the life time of objects is determined by Ada's
> language rules (and not by the type system), isn't it
> normal to expect that the language defined wrecking
> ball smashes the thing only after it has finished?

Finalize is expected to have the object fully operational if called for the
first time. Which is not the case for the task components.

> What would be the alternative?  Would it be that the
> programmer then has to actively manage all parts of
> destruction  himself?

Not at all. The alternative is for the user-defined
constructor/destructor's hook to meet all components valid when called.
Finalize is not such a hook.

> When an implementation collects garbage, when would
> the "destructor" run?

The destructor of the type T to be called before the memory allocated for
the object loses its attribution to the type T. Note that this does not
imply deallocation. For instance when S is demoted to its base type T, the
destructor of S must be called to make a T out of S.

>  Do finalization and RAII destruction(?)
> have to be separate things?

Finalization is another word for destruction. (I am not a language lawyer
and don't about what RM might say about it)

Again, observe that promotion requires a partial construction while
demotion does a partial destruction. The primitive operation Finalize is a
partial destructor. A complete destruction includes the bodies of the
Finalize from all bases and destructors of all components.

Note also that a consistent model must also provide hooks for
promotion/demotion to the class (e.g. S -> T'Class, T'Class -> S).

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