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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-13 11:31:51 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc01.POSTED!not-for-mail Message-ID: <3F636281.7010509@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Can MI be supported? (Was: Is the Writing on the Wall for Ada?) References: <3F5F7FDC.30500@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc01 1063477906 24.34.139.183 (Sat, 13 Sep 2003 18:31:46 GMT) NNTP-Posting-Date: Sat, 13 Sep 2003 18:31:46 GMT Organization: Comcast Online Date: Sat, 13 Sep 2003 18:31:47 GMT Xref: archiver1.google.com comp.lang.ada:42453 Date: 2003-09-13T18:31:47+00:00 List-Id: Warren W. Gay VE3WWG wrote: > CONCLUSION: > > In any case, I think MI _CAN_ be supported, where someone > were to address the "MI qualification" issue in a way that > can be agreed to. If you look at the mix-in example I just posted you can use the names of the intermediate packages to get at the different operations. For example if Size and Color had both been derived from integers, then Set(Some_Object,2); --would be ambiguous; Set(Some_Object, Color'(2)); -- fine Set(Some_Object, Color(2)); -- okay, due to preference rule. My_Color.Set(Some_Object, 2); -- also works. My_Resize.Set(Some_Object, 2); -- still ambiguous. > Did I miss other problem(s) with MI that qualification > would not be able to solve? Perhaps there are some > problems within the Ada framework that I have not > anticipated here. The problem with double direct inheritance has nothing to do with ambiguous methods. And as you can see if you look at the example I just posted, Ada already HAS multiple inheritance. The problem with double direct inheritance has to do with membership properties. With direct inheritance, say from types A and B, you need to be able to view an object as as if it isa A and isa B. So where is the problem? It is in the transitivity of isa. In Ada there are many ways to create a new type or subtype which either subset or exend the parent type, but only one method of preserving the transitive isa relationship: subtype A is B; As you can see, in Ada the transitive isa relationship holds with two subtypes of the same type which do not impose a constraint: type A is private; subtype B is A; subtype C is A; X: C; X isa A, and therefore X isa B. If type C is derived from B and also from A, as can occur with mix-ins and interface inheritance: type A is ...; type B is new A [with ...]; type C is new B [with ...]; X: C := ...; Y: A := ...; Then X isa member of C, X isa member of B'Class, and X isa member of A'Class, but a Y is not necessarily a member of C'Class, or even viewable as a member of A'Class, and all is well in the world. If somehow you added a notation for direct inheritance from two different types or classes you would have any C isa A and any C isa B, and therefore any A isa B. The point I was trying to make with the Point example, is that even when the state information is identical in size and type (i.e. structural equivalence), its MEANING is different. The first state variable can't represent both displacement on the X-axis and the vector length. (Although, as it happens, if the second state varible is zero, there is no problem. ;-) In Ada we have gone the extra mile so that you can do view conversions on objects to an ancestor type. So even when you derive from a tagged type and add state, you can still do a view conversion and look at an object of the child type as if it isa member of the parent's class. The tag is still visible, which is why the isa relation is to the parent's class, not to the definite type. For non-tagged types, view conversion does satisfy the isa relationship. Notice that mix-ins take advantage of this. When you use mix-ins, the new type has all of the mix-ins as ancestor types, so if you have a generic formal package parameter of the form: package Bar is new Foo; Or a formal derived type parameter of the form: type Foobar is new Foob with private; Then a mix-in type (or the corresponding generic package instance) can be used to match the formal. Could we allow in Ada a new construct: subtype A is B with C; Sure. In fact the new proposal for interface inheritance looks similar to that. It would mean to directly inherit from B and add the C interface. An A isa B, an A isa C, a B isa A, but an instance of C is not necessarily an A. In practice, that is not all that useful, since maintaining the isa relationship would limit what the interfaces could add. So the new notation is actually: type A is new B with C, D, E; X: A := ...; Y: B := ...; ... X := A(Y); -- legal This way A extends B, there exist views of X as a B, C, D, or E. Y can be converted to an A. The interfaces are part of the type extension of B into A, and there are no transitivity problems: type F is new G with D; Z: F; ... X := A(D(Z)); -- illegal. -- Robert I. Eachus "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh