Re: abstract sub programs overriding

["Robert I. Eachus" <rieachus@comcast.net>]

Hyman Rosen wrote:

> So he's not right, because it's not impossible, just very unusual.

No, he is right.  As a langauge lawyer I know how to "get around the 
rules."  But counting something that you can do in a child package of 
Ada.Controlled or Ada.Limited_Controlled as a property of the language 
is silly.  There are other ways to work around the rule, but they are 
similarly unlikely.  So things that can be done with a user defined type 
derived from some other user defined type are interesting, but in the 
end at least one Intialize procedure will be called for all user defined 
controlled objects.

> Anyway, let's see if I understand. You are saying that in Ada, it
> is unusual to call Parent.Initialize(Parent_Type(Child_Object)) from
> Child's Initialize. That seems odd to me; how does the child know that
> the parent can do without this call? If it can be so blithely ignored,
> what good is having it in the first place?

No, as I said, there are two common idioms, the first is to call the 
parent Initialize AFTER doing any initialization work needed on the 
fields that occur only in the child.  (The second is discussed below.)

> You also say that "It is much more common, however, for such a call to
> be done for only the parent part of the object, for example when creating
> a child object using an aggregate." Isn't it the case that when you do 
> that, Child's Initialize won't be called at all?

Yes, the parent object will be Initialized, and for a Controlled (not 
Limited_Controlled) aggregate assignment, the object created in this way 
will be Adjusted as a whole.  But I think you missed my main point, that 
the Initialize procedure for the child type may use an 
extension_aggregate to create the object, then make any necessary 
adjustments, either explicitly or implicitly through the Adjust call 
made for regular Controlled types.  Obviously you don't want the child's 
Initialize procedure to be called on extension_aggregates, because an 
extension_aggregate may necessary inside the Initialize procedure of the 
child type.

Sort of a meta comment here, and it goes back to what I said above.  All 
objects of types descended from Controlled or Limited_Controlled have 
fields that are not visible to an ordinary user.  This means that for 
most users what they can do in a child package of Ada.Controlled is of 
limited interest.  This is really what makes the only interesting cases:

procedure Initalize(Object: in out Child) is
begin
   Do_Something(Object);
   Initialize(Parent(Object));
end Initialize;

or:

procedure Initialize(Object: in out Child) is
begin
   Object := (Parent_Type with ...);
   Do_Something_Else(Object);
end Initialize;

Now notice that it is trivially obvious that in Do_Something or 
Do_Something_Else, Object is not fully initialized.  But we are inside 
the Initialize procedure, so of course it hasn't completed yet.  As a 
programmer it is not hard to choose whichever idiom is appropriate for 
the type you are defining.  But it is also the case that for any 
controlled Object users cannot bypass the first stage of initialization, 
where Object is created and all components are initialized to their 
default values. (Or in the extension aggregate case, given valid 
non-default values.)

So yes, there are areas where user written code can access an object 
that has not yet been completely initialized.  But in practice, as a 
user you will find that once you get rid of any bugs (and exceptions) 
inside Intialize, Adjust, and Finalize, that code written by others, 
including the authors of types derived from your types, cannot mess up 
the invariants of your type.

> You also say that as a matter of policy, Initialize should not make
> a dispatching calls because it is likely to be incorrect. That's what
> C++ avoids by preventing dispatching from going to parts of the final
> object which are not yet constructed.

No, I did not say that.  I said that attempts to down convert an object 
to a child type will fail. Technically, it is not possible to do a VALUE 
conversion from a parent type to a (tagged) child type.  You will find 
that in some cases a view conversion is legal, but an attempt to assign 
to that view will often raise Constraint_Error (or Program_Error).

I am not going to try and describe here when conversions are illegal, 
when they will raise Program_Error, and when they will raise 
Constraint_Error.  All that is spelled out in RM 4.6, and it is hard to 
say it in fewer words. (RM 4.6 is cryptic enough!  You might want to use 
the AARM instead: http://www.adaic.org/standards/95aarm/html/AA-4-6.html)

So what I was saying was that it is possible to put an view conversion 
to a child type inside an Initialize procedure, but if you try to write 
the code, you will find yourself dodging lots of land mines.  For 
example, the body of the package which defines the parent type is going 
to have to with the package that defines the child type.  But if you are 
not very careful, there will be no valid elaboration order for the 
corresponding package bodies.  There are lots of land mines that have 
nothing to do with the issues you are trying to raise here that can come 
up if you try what you indicated.

It is like discussing the speed at which you can drive southbound down 
the northbound side of a divided highway.  You may be interested in 
whether or not the banking of the curves works correctly.  However, 
there are going to be lots of impediments to doing the actual experiment 
that have nothing to do with curves, banking, or automobile suspensions. 
  (They would have something to do with license suspensions though. ;-)

-- 
                                           Robert I. Eachus

"The only thing necessary for the triumph of evil is for good men to do 
nothing." --Edmund Burke