Re: basic basic ada question

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

On Mon, 23 Oct 2006 16:30:23 +0200, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>>>> 1. T's components
>>>> 2. S's components
>>>> 3. T (Initialize)
>>>> 4. S (Initialize)
>>>> 5. T'Class
>>>>     -- here a class-wide constructor defined for T can safely dispatch to a
>>>>     -- some primitive operation overridden by S
>>>> 6. S'Class
>>>>
>>>> [I am not sure about ordering 5 and 6]
>>> And I am not sure why do you need 5 and 6 at all - you've already done 
>>> the whole job in 3 and 4.
>> 
>> You cannot dispatch to the procedures of S from Initialize of T, i.e. from
>> 3 before 4 is done. S might be unusable. The step 5 is for this purpose.
> 
> But why would you need to dispatch to S after step 4?

type T is abstract ...;
function Greeting_Message return String is abstract;
procedure Initialize (X : in out T) is
begin
   Put_Line ("Hi," & Greeting_Message (T'Class (X))); -- Illegal!
end Initialize;

type S is new T with ...;
function Greeting_Message return String is
begin
   return "I am T!";
end Greeting_Message;

>>> For me 4 should 
>>> be the last step and 5,6 should not exist at all.
>> 
>> Which is indeed a maintenance disaster. Consider GUI interfaces built in
>> C++. Note that practically all of them have procedures like OnInit, because
>> it is eventually impossible to construct widgets fully functional. Ada
>> suffers this as well. For example, it is impossible to embed task
>> components. You need special Start/Stop entries in the tasks.
> 
> But then, the construction process will involve the interaction with 
> other objects and that's why automating all 6 steps above for a single 
> object will not necessarily solve the problem. In the case of GUI, you 
> might want to construct widgets somewhere between 4 and 5. The 
> OnInit-like procedures provide explicit hooks for this.
> I any case, if there is a way to get rid of OnInit, I think it should be 
> possible without 5 and 6 anyway - possibly with additional objects 
> involved instead, but I'd prefer more elaborate collaboration pattern 
> (which is explicit in the design) in place of more elaborate 
> construction mechanism (which is implicit).

OO spaghetti, in short...

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