Re: type extension vs. inheritance

[nebbe@lglsun.epfl.ch (Robb Nebbe)]

In article <RTOAL.6.00162786@lmumail.lmu.edu>,
RTOAL@lmumail.lmu.edu (Ray Toal) writes:

|> 
|> Ada 9X has "type extension" and in the Rationale I saw an example
|> where a 3-D box was derived from a 2-D rectangle by adding a
|> "depth" field to the width and the height.
|> 
|> 1.  Is this something one would really do in practice, or was
|>     it just an example to illustrate type extension?

In my opinion it is more an example of what you can do than what you
should do (but I didn't write the Rationale so I don't know what they
think).

|> 2.  But even if the answer to (1) is "just an example" a better
|>     question is, in industry, how many applications REALLY benefit
|>     from these IS-A hierarchies anyway??

If you need to implement a hierarchies of abstractions then inheritance
is the way to do it. It is cleaner, easier to modify and maintain. There
are two main uses for these hierarchies:

1. They better document the structure of the software thus facilitating
its maintenance and extension but dispatching (polymorphism) is not
used.

2. You need to refer to a class of abstractions. How necessary this is
depends a lot on the domain you are working in but in most cases I find
that composition is a more common mechanism than classification.

|> 3.  And how would one, in Ada 9X, implement in a nice way the
|>     derivation of a square from a rectangle?

There are two ways to model this, semantically what you want is something
close to (* see note):

   type Rectangle is private;
   subtype Square is Rectangle;

but classification is probably best used like:

   type Four_Sided is abstract tagged private;

   type Quadrilateral is new Four_Sided with private;
   type Parallelogram is new Four_Sided with private;
   type Rectangle is new Four_Sided with private;
   type Square is new Four_Sided with private;

and then declare conversion functions between different types to represent
overlaping domains, which is not necessarily the same as a subtype.

Robb Nebbe

*note:
The problem is that you can't associate the necessary predicate with the
subtype Square like you can with numeric types so you would probably
declare a function Is_Square and distribute the complexity of testing
a rectangle to see if it is square acrossed the clients. It might be
worth looking into extending the pragma Assert in GNAT to do this but
this is pure speculation.