Re: 2 Ada 95/05 language design questions

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

On 15 Feb 2007 08:21:48 -0800, pnkflyd831@gmail.com wrote:

> I find Ada to be an excellent embedded, real-time, OO language.
> However I've noticed over the course of my 3 years programming with
> the language 2 ways in which the language behaves that I question the
> designers on their rationale.
> 
> The first question deals with the decision not to allow the
> declaration of abstract subprograms within the private part of a
> package (that contains a public abstract tagged type, and uses it as
> the controlling operand).  See Ada 05 LRM section 3.9.3(10).  The
> Annotated LRM gives a rational (derived tagged types not declared in
> child packages would not have visibility to these abstract
> subprograms), but wouldn't the better option to be to force derived
> tagged type to be declared in the same or child packages than to have
> to make public the abstract subprogram?  I do not like the idea of
> allowing external objects access to methods that could potentially
> leave the aforementioned class objects in an inconsistant state.
> (Attempts to impliment the Template Method design pattern suffer from
> this issue)

Yes, this rule is sometimes quite annoying. A similar problem is that
tagged-ness of private types cannot be hidden.

   type S is abstract private; -- Illegal
private   
   type S is abstract tagged null record;

There is nothing wrong in private type extensions.

> The second question deals with the decision not to have derived tagged
> types inherit the "primitive" classwide subprograms of their publicly
> declared parents.  See Ada 05 LRM section 3.4(16,17/2, & 23/2) which
> states that only primitive operations are inherited and made visible.
> In Ada 95 it seems silly to have to with in the package where the
> classwide subprogram is declared to use it, and then the package
> reference has to be repeated every time the classwide subprogram is
> called unless a use clause is present.  The calling object should not
> have to distinguish between dispatching and classwide operations when
> they have a child derived type view of the object.   In Ada 05, the
> impact is less severe because of the dot notation,  but I am still
> curious as to why the decision was made. (Code which works with the
> child derived type object instead of the parent view of the object
> suffer from this issue).

A class-wide subprogram is not primitive. It is defined on T'Class which is
a type distinct from T. Subprograms defined on T'Class are treated
uniformly. Otherwise, it would add an irregularity to the language rules.

As for inherited primitive subprograms their origins don't become any
visible. Consider this:

package P1 is
   type T1 new tagged null record;
   procedure Foo (X : T1);
end P1;

with P1;
package P2 is
   type T2 new P1.T1 with  null record;
end P2;

Now somewhere where P2 is use-d, but P1 is not:

   X : P.T1;
   Y : T2;
begin
   Foo (X); -- Illegal P1.Foo is not directly visible
   Foo (Y); -- Legal P2.Foo is visible, P2.Foo is inherited P1.Foo

You can consider an act of inheritance as a declaration of a *new*
subprogram which body is generated by the compiler:

   procedure Foo (X : T2) is -- This will be visible
   begin
      P1.Foo (P1.T1 (X));
   end  Foo;

P2.Foo is a composition of P1.Foo o P1.T1. Inheritance makes P2.Foo visible
in P2 as any other subprogram declared there. It does not influence P1.Foo.

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