Re: 2 Ada 95/05 language design questions

["Adam Beneschan" <adam@irvine.com>]

On Feb 15, 8:21 am, pnkflyd...@gmail.com wrote:

> 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).

I think your solution could lead to problems.  For one thing, while an
operation can be a dispatching operation of only one tagged type, it
can have several class-wide types in it.  Consider:

   package Pak1 is
       type Root1 is tagged record ... end record;
       type Root2 is tagged record ... end record;
       procedure CW_Operation (X : Root1'Class;
                               Y : Root2'Class);
   end Pak1;

   package Pak2 is
       type Child1 is new Pak1.Root1 with record ... end record;
       type Child2 is new Pak1.Root2 with record ... end record;
       -- (A) inherited subprograms...
   end Pak2;

How many implicit declarations of CW_Operation would there be at (A)?
I count three.  And they'd be overloaded, which means that if you
tried to call CW_Operation on a Child1 and a Child2, all three of them
would be possible meanings for the identifier CW_Operation, and you'd
have to use qualified-type notation on all the parameters to keep the
results from being ambiguous.  (There may be ways to solve this by
adding more rules to the language to say that ambiguous calls are OK
if all the subprograms are just inherited versions of each other, so
that the same code would be called anyway, but this can start to get
very complicated.)

Anyway, the Object.Operation notation of Ada 2005 was put there to
solve this exact problem.  It's unfortunate that the designers missed
this particular problem when designing Ada 95, but it happens---if
they had taken the time to make sure that no flaws were missed, we'd
be calling it Ada 2317 instead of Ada 95.

                      -- Adam