Re: orthogonal inheritance and extension aggregates

[Adam Beneschan <adambeneschan@aol.com>]

OK, I've thought about this a little more.  First of all, I think the problem might be unique to Ada.  Ada allows you to write a generic that takes an arbitrary tagged type and defines a new extension of that type.  The one other OOP language I'm most familiar with, Java, just doesn't allow this:

   public class ExtensionOf<T> extends T is ...

is illegal.  (T is a "type variable" which is pretty much the equivalent of a generic formal tagged type, and "extends" is how you write derived types; but "extends" doesn't allow "type variables" in its syntax.)

If it did allow it, the new type wouldn't inherit T's constructors, since constructors just aren't inherited.  Ada does try to inherit the "constructors", i.e. functions that return values of the type; but of course the inherited constructors make no sense because they cannot initialize extension components.   Thus, an inherited constructor (for a concrete type) is illegal and must be overridden.  But, as this example shows, this can't be done when the parent type is a generic formal type, since we don't know what functions might be defined for the actual.  

It doesn't make sense for the Extension generic package to try to provide versions of all the constructors that might be defined for the actual type.  I think that the "right" way to handle this would be for Extension to define a function that takes a Parent object and returns an Extended object:

   function Create_Extended (Obj : Parent) return Extended;

where Create_Extended would initialize fields and whatever other action is necessary, and then the code that uses it would do something like

   E1 : Extended := Create_Extended (To_Vector (...));

assuming that Extended were not declared "abstract".  This doesn't solve the legality problem, though.

So I'm thinking that the rules in 3.9.3 need to be relaxed.  3.9.3(4-6) says that for a derived type, if the parent type has any abstract subprograms or functions with a controlling result, then (1) if the derived type is abstract, the inherited subprogram is abstract; or (2) the subprogram must be overridden, except in null extension cases.  What I'm thinking is that we need a (2a) that says something like: if the parent type is a generic formal tagged type or type extension, and the derived type is not a generic formal, and if the subprogram is not abstract [which means it must be a function with a controlling result], and if no overriding subprogram is explicitly provided, the subprogram is overridden with an implicit subprogram that does nothing but raise Program_Error.  This should solve the problem in a case like this--where the language demands that some subprograms be overridden but does not provide any mechanism for doing so.  I'm assuming that if this were the case, Extended would no longer need to be "abstract".  (If it were, this change wouldn't be sufficient.)

Any thoughts?  Does this seem like a possibly worthwhile proposal?

                              -- Adam