Re: Ada 2005 puzzle

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

On Sat, 21 Jul 2012 15:46:47 -0700 (PDT), Maciej Sobczak wrote:

> W dniu pi�tek, 20 lipca 2012 14:49:14 UTC+2 u�ytkownik Dmitry A. Kazakov napisa�:
> 
>> I meant here a different thing. If you have some dispatching operations to 
>> be performed upon initialization,
> 
> I'm not sure what possible use-case would motivate it - I don't see any in
> the container's interface. Containers are not supposed to be more smart
> than necessary, they just have to keep objects.

But they cannot be more stupid than objects they keep. The use case is a
container of T'Class. T is abstract. Upon its initialization, which is
non-abstract, the initialization calls to an abstract operation Foo:

procedure Initialize (X : in out T) is
begin
   ...
   Foo (T'Class (X));
end Initialize;
 
>> Let you have a hierarchy of types  T1:>T2:>T3. Then construction should run 
>> as follows:
>> 
>> stage 1
>> T1 constraints evaluation
>> T2 constraints
>> T3 constraints
>> 
>> allocation
>> 
>> stage 2
>> T1 initialization
>> T2 initialization
>> T3 initialization
>> 
>> stage 3
>> T1'Class initialization, only here we could dispatch on T1'Class
>> T2'Class initialization
>> T3'Class initialization
>> 
>> 1-3 cannot be effectively fused into single operation
> 
> Stage 3 is implicit, so we don't have to care,

Actually we have to, not only because people want to dispatch upon
initialization. The same problem arise with Rosen's trick. Most typically
when a component of T1 is a task carrying T1'Class as an access
discriminant. When you wanted a rendezvous with the task upon
initialization, you get a nice deadlock (or Tasking_Error). Component tasks
are created during 2. They start no earlier than during 3.

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