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-16 13:33:45 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!rwcrnsc53.POSTED!not-for-mail Message-ID: <3F677389.80009@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> <3F636281.7010509@attbi.com> <76hbmvg0fvuii8u4dm0jjq2pp2cjh5ppur@4ax.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: rwcrnsc53 1063744422 24.34.139.183 (Tue, 16 Sep 2003 20:33:42 GMT) NNTP-Posting-Date: Tue, 16 Sep 2003 20:33:42 GMT Organization: Comcast Online Date: Tue, 16 Sep 2003 20:33:42 GMT Xref: archiver1.google.com comp.lang.ada:42583 Date: 2003-09-16T20:33:42+00:00 List-Id: Dmitry A. Kazakov wrote: > No, it is "IS-A" which leads to incompatible logical conclusions! > (:-)) Especially when "substitutable-for" and "interchangeable-with" > are mixed. Correct. I just read an interesting paper on "traits" for Smalltalk. It of course explained the shortcomings of "true" MI. (It doesn't work whether you want to call the reason the overriding problem, the diamond inheritance pattern or whatever.) It also explained the disadvantages of mix-in style inheritance. Of course, the major problems with mix-ins in other languages don't occur in Ada. (In Ada you have explicit control of visibility, and the implementor of the type can always name and call any methods that might be hidden or overloaded, and even rename them to make them visible to users of the final concrete type. And of course, any methods that don't make sense for the concrete type can be hidden from users.) And finally it defined a method of creating and sharing traits. It looked like a very interesting design paradigm. It will be possible to implement traits in Ada with interfaces. But even without interfaces you can implement the pattern using mix-ins. Of course, mix-ins allow you to add state, and traits don't, but you can always implement at trait with generics. Basically with traits you expect the "base" object to have all the necessary state, and the traits manage existing state variables. To use the cartesian and polar co-ordinate example, you might have all objects with a location attribute as part of its state. Then the cartesian and polar trait addins would manage that part of the state. The norm would be for some objects to have polar co-ordinates and others to have cartesian co-ordinates, and the actual trait inherited would determine how co-ordinates were managed: type Location (Polar: Boolean) is record case Polar is when True => R, Theta: Float; when False => X, Y: Float; end case; end record; type Some_Object is ... Where: Location(Polar => True); ... end record; generic type Extended is new Object; package Polar_Coordinates is function Get(Obj: in Extended) return Location; procedure Set(Obj: in out Extended R, Theta: in Float); ... end Polar_Coordinates; and so on... But I think I'll stick to mix-ins for now. -- 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