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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Design By Contract Date: 1997/09/08 Message-ID: #1/1 X-Deja-AN: 270890315 References: <5ulurp$aj8$1@miranda.gmrc.gecm.com> Organization: Estormza Software Newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1997-09-08T00:00:00+00:00 List-Id: In article , nickle@compulink.co.uk wrote: >> For example Eiffel has direct support for multiple inheritance (MI). Ada >> requires you to play games with generic parameters in order to achieve >> the same effect. Thinking more about it, it really does make sense to implement mixin inheritance this way in Ada 95. The original poster probably wasn't "thinking in Ada." To declare an abstract data type in Ada, you do this: package P is type T is tagged private; ... end; Clients of type T with package P to get visibility to the type: with P; procedure Q is O : P.T; ... Now as far as clients of T are concerned, it doesn't matter whether P is a non-generic package, or the instantiation of a generic package. His manipulation of the type is the same. For example, we could have done this: generic ... package GP is type T is tagged ...; ... package P is new GP (...); My point is that from a client's point of view, it's exactly the same. He wants a type that has certain operations, so he withs a package containing that type. Now we have a certain abstraction into which we want to mix some other operations. What we're debating is how easy it is for the _mixer_ to do this. But who made this executive decision that MI is a better mechanism than genericity for combining abstractions? The key thing is that we're able to combine abstractions this way, _without_ an additional language feature. (This doesn't mean MI is bad, only that it's not needed.) Existing language mechanisms do _exactly_ what we want. The irony is that this isn't anying especially new: in Ada 83 we were _already_ combining abstractions this way (example: extending a list type with utility operations by importing the list type as a generic formal parameter). To say that MI is a "more elegant' mechanism of implementing mixin inheritance, or that Ada requires you to "play games" with generics (thus reducing the Ada mechanism to the status of a mere "idiom"), is a pretty impuissant argument. (Like my new word?) The generic technique is what Ada programmers have been doing all along (though not quite as simply as in Ada 95), so I'm not clear what you'd buy by using yet another mechanism whose superiority is only putative. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271