From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c5ca2cbae60e9fee X-Google-Attributes: gid103376,public From: Ehud Lamm Subject: Re: OO puzzle Date: 1999/12/23 Message-ID: <83sq9g$5ml$1@nnrp1.deja.com> X-Deja-AN: 564075891 References: <386102F6.56CEFA22@averstar.com> X-Http-Proxy: 1.0 o-proxy.cc.huji.ac.il:8080 (Squid/2.2.STABLE4), 1.0 x42.deja.com:80 (Squid/1.1.22) for client 132.64.12.88, 132.64.1.34 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Thu Dec 23 09:33:53 1999 GMT X-MyDeja-Info: XMYDJUIDehudlamm Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Date: 1999-12-23T00:00:00+00:00 List-Id: In article <386102F6.56CEFA22@averstar.com>, Tucker Taft 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.