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-12 10:43:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 12 Sep 2003 13:28:34 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1063387699 198.96.223.163 (Fri, 12 Sep 2003 13:28:19 EDT) NNTP-Posting-Date: Fri, 12 Sep 2003 13:28:19 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:42424 Date: 2003-09-12T13:28:34-04:00 List-Id: Dmitry A. Kazakov wrote: > On Wed, 10 Sep 2003 19:47:46 GMT, "Robert I. Eachus" > wrote: >>Hyman Rosen wrote: ... >>Notice that if I do interface inheritance from the two concrete types, I >>can program the underlying routines to do something sensible when say >>adding a polar displacement to a cartesian point. By the way, notice >>that in Ada if I want I can provide a type with both cartesian and polar >>implementations. As a programmer, I can go further and add the >>"missing" operations like adding a cartesian point to a polar point. Do >>everything right and "+" will just work. That is a kind of multiple >>implementations of a type that I can live with, and I don't know of any >>other language where you can do such overloading. (It is tricky enough >>to get right in Ada...) > > It is a good example and it shows that there should be both > implementation and interface inheritance. Then for interface > inheritance, it should be possible to inherit from concrete > (non-abstract) types. > > In the case of multiple views on the SAME point object, it is clear > that implementation x 2 inheritance would be a wrong solution, because > it would define a 4D point! A right solution is either: > > 1. implementation inheritance from either Cartesian or Polar point and > interface inheritance from another. > > 2. interface inheritance from both. > > But this does not prove that multiple implementation inheritance has > no place. I have tried to stay out of this fray, and probably should ;-) But I would add that it doesn't really matter that the MI example makes no sense, or is poor design. I think what is being suggested is that the language should allow the programmer to model anything he can conceive of - even poorly formulated models! The whole crux of the MI issue is about resolving the clashes of method and attribute names that MI provokes (or leads to the possibility of). Certainly, eliminating MI is one way to solve the problem! Interfaces is another way to hand-wire it for yourself (ie. working around the problem). But I can't help but think that MI is "usable" with the correct amount of care given to it. Other language(s) allow you special syntax to either: - resolve the ambiguity in the declaration and - resolve the ambiguity in the reference(s) (methods and attributes) I have forgotten the specific language(s) that make these allowances. Was it Eiffle? No matter.. What follows is _just_ discussion, _NOT_ a proposal 8-) so don't flame me and the group for its ugliness ;-) One conceptually ugly way to handle a given MI clash, is to number them (the inherited from objects). In fact, I am sure that many have suggested something along this line before.... Someone said something earlier about couching the MI members in records for example: but take that idea and reference them by number (for this discussion): 1, for the first inherited object, 2 for the next etc. Methods could work along the same idea. Again, I am not in favour of using numbers in real programs for all of the obvious reasons, so just bear with me here, for discussion's sake. Once this is done, then clashing members (attributes) and methods can be qualified in the new objects internals and for general applicatoin use (let's call these "MI qualifiers"): -- Inside some method of Combo_Point which inherits from -- a cartesian point and a polar point object: 1:X := 0; 2:R := 0; Object methods could be resolved (in an ugly fashion) as follows: procedure My_App P : Combo_Point; begin 1:Set_Point(P,New_X,New_Y); OK, what was my point? Well all of this is very ugly for obvious reasons, but the point is that if the ambiguity for MI is resolved, the whole MI issue goes away. Unless perhaps I am missing some other related issues like converting a MI object down to some base class (but again, the proper qualifiers should be able to help). You could say that the "MI qualifier" is unnecessary when no conflicts occur. Certainly the compiler would be capable of making that determination. Under those circumstances you could say that this "MI qualification" then would be illegal. This of course breaks badly, if in the future a conflict is introduced due to a design change, causing all clients of the objects to fail to compile (but maybe that's a good thing?) In conflicting cases, the compiler would have to insist that you use "MI qualification" (in whatever elegant form that someone can come up with -- here we used numbering only for illustration purposes). 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. 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. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg