Re: OO puzzle

[Tucker Taft <stt@averstar.com>]

Ehud Lamm wrote:
> 
> The recent threads about languages for OO development, made me think the
> following may interest readers here.
> ...
> Basically this means that is you have a function
>    Stack.Push(Node)
> 
> and you inherit to create Stack_Array than you can also change the
> argument Node to something that inherits from Node:
>   Stack_Array.Push(Node_Array)
> 
> Can you do this in Ada (think of what we saw above about comparable)? So
> what is the Ada solution in this case? Can you do this in Java (is Java
> "covariant")?

Ada is automatically "covariant" in all of the "controlling" operands
(and result) of a primitive operation.  Java is not covariant in its 
operands (other than the implicit "this" operand, of course).

Ada does not support covariance for operands of an unrelated type.
This has a number of nasty "system validity" issues that Eiffel presumes
will be caught by the linker.

When you want to do something like this in Ada, the best thing to do is 
define a generic and either use a formal derived type, or use
a formal private type with specified operations (this is the
most flexible approach).

> ---------------------------------------------------------------------
> 
> Now how does this affect design?
> This example is again from the Eiffel book.
> 
> 1. Truck_Driver IS-A Driver (one hierrachy)
> 
> 2. Motor_Vehicle (and all its kids)  support the operation
> register_Driver(d:driver) the paramter is of type driver above.
> 
>    Car IS-A Motor_Vechicle
>    Truck IS-A Motor_Vehicle
>      Truck wants to override register_driver(d:truck_driver) becuase only
> truck drivers should be allowed here.

This implies that you will have to deal with the system validity
issues, if someone tries to register a non-truck driver of a vehicle, and
the vehicle turns out to be truck.  In most cases, this would imply
a run-time check, or a "pessimistic" link-time check.

> Can yuo do this in Ada? Try, and show your error messages! How can you do
> something to achive the same result, in Ada?

The simplest solution is to create a new operation (perhaps with
a new name like "register_truck_driver").  The existing register_driver
operation could be overridden with one that performs the appropriate
conversion to truck_driver (which will automatically do the relevant
run-time check) and then calls the register_truck_driver operation.
Either one could be called from outside the abstraction,
but the "register_truck_driver" version would have no chance of
run-time-check failure, and instead would enforce the check at compile-time.



> 
> I qoute:
> "Examples of this kind, with two prallel inheritance hierarchies, are a
> constant occurrence in the development of systems and their class
> hierarchies. Many appear in the Data Strcuture Library" (the Eiffel
> library of trees etc.) "For example, to describe a doubly linked list,
> TWO_WAY_LIST inherits from LINKED_LIST; to describe two-way chained linked
> cells, BI_LINAKBLE inherits from LINKABLE. The list classes have
> procedures for manipulating list celss, such as put_linkable_left, which
> quite naturally take arguments of type LINKABLE imn LINKED_LIST and
> BI_LINKABLE in TWO_WAY_LIST"
> 
> A bit complicated hierrachies, but this is simple comapred to what you may
> find in real life applications!
> 
> Can you do this in Ada? How?

See above.  Trying to do this "automatically" with parameter covariance
is in some ways sweeping the issue under the rug.  Additional
run-time checks may be inevitable, meaning that the operations should
perhaps not be given identical names.  As mentioned above, using
generics or adding new operations are two approaches.  Given
any particular problem, the solution would probably be obvious.

Given a general statement such as "this language has this feature, 
what is the equivalent in that language" can be a waste of energy.
Each language gives you a toolkit.  The toolkits are generally not
identical.  To pick one tool from a toolkit and try to construct
an equivalent tool using tools from another toolkit may be pointless.
The real question is how effectively and safely can each toolkit,
given the tools it contains, solve the problems of interest.  So the
key is to focus on the problems of interest, not on replicating
particular tools.
 
> ...
> So what do you guys suggest as the proper Ada way in these cases?

See above.
> 
> Ehud Lamm mslamm@mscc.huji.ac.il
> http://purl.oclc.org/NET/ehudlamm <== My home on the web
> Check it out and subscribe to the E-List- for interesting essays and more!

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA