Re: OO puzzle

[Ehud Lamm <mslamm@mscc.huji.ac.il>]

In article <386102F6.56CEFA22@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> 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.

This issue of system validity is discussed in the "Eiffel the language"
book, from which I took the examples. If any one is interested in
looking it up. This is indeed the heart of this issue.

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

Yes, my approach is to use generics as much as possible. Simply love
the concept.
But how would you use it in the Truch driver example below?


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

This issue of run-time/pre run-time checking is the crux of the matter.
I was under the impression that system validity issue are checked
before runtime. Of course otherwise the problem is much simpler, since
explicit conversions in the body of the inherited routine would give
you a constraint_error if the types do not match. Checking the 'class
is also possible to do explicitly.
I assume the importance of catching errors before runtime is evident.
Now can we do it nicely in this case?

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

Right but someone using the abstract interface, may end up having a run-
time error. Just so we are claer on the implications here.
This is indeed sometimes an acceptable solution.

> >

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

I am not sure obvious to everybody! My students do not find it obvious
(and as a matter of fact neither do I all the time!)
I'd be happy if you could elaborate on the issue of the inevitability
of runtime checks. As far as I see, _in principle_ these issues can be
checked at compile time (unsless of course we are delaing with dynamic
binding). So is the issue the cost of the checking, or is there some
issue I am fogetting right now?


>
> Given a general statement such as "this language has this feature,
> what is the equivalent in that language" can be a waste of energy.


It seems people understood me as doing this. But this is exactly what I
do not like, and didn't try to do!
My attempt was to help clarify the different approaches. I am not
saying off hand "emulate." But I do think that it is not a simple
matter to arrive at the level of understanding you have... The examples
illustrate that something that looks like an acceptable design, is not
automatically codable. You have to understand the underlying
methodology, and have an intuition for the techniques.
I think this discussion is useful for this purpose (e.g, clarifying the
things that are compile time and run time).
Actually in most respects I prefer the Ada tagged type model to others,
since it seems clearer to me. But this is not the issue. The issue is
having a good enough understanding to compare and analyze. This, I
think, is not a waste of energy.


--
Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm
Check it out and subscribe to the E-List


Sent via Deja.com http://www.deja.com/
Before you buy.