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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Date: 1997/07/14 Message-ID: #1/1 X-Deja-AN: 256796992 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: Organization: CSC Australia, Sydney Reply-To: donh@syd.csa.com.au Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-14T00:00:00+00:00 List-Id: Matthew Heaney wrote: :In article <33C4AF0E.339D@calfp.co.uk>, Nick Leaton wrote: : :>> Different languages have made different choices with respect to whether all :>> types should be part of a common hierarchy. That Eiffel did so, and Ada :>> did not, should not be construed as better, just different. :> :>I'm not sure about this. If you don't have a common hierarchy, then that :>precludes you from using a common root. Now this is useful when we look :>at container classes. It is particularly useful when you can constrain :>the type that is store in a container to a particular type. : :I think there is confusion here between what one does versus how one does it. I think what Nick means is that because Ada does not define Integer and Float as classes inheriting from a common ancestor class Numeric, they are less flexible than in Eiffel. In particular, you can't declare a generic Numeric container class and constrain *through inheritance* to store Integers or Floats. Consequently, you can't use a Numeric container polymorphically by substituting an Integer or Float container. Also, you can't store both Floats and Integers in the same Numeric container. These things are simple and straightforward to do in Eiffel because INTEGER and REAL are both classes (as well as types) inheriting from class NUMERIC. In Ada, there is something like a notional Numeric *type* having properties like assignment and addition but because it is not a class (tagged type), it's not extensible through inheritance. You may be able to extend using Ada's *other* inheritance mechanism - derived types - but that doesn't allow polymorphism so you miss something compared with Eiffel. :In Ada, you can constrain the type you use to parameterize a container :class, it's just that the mechanism for doing so is different from Eiffel. [examples of constrained numeric types unrelated by inheritance] :I can constrain the type so that it only takes tagged types (those that :have type extension): [example of constrained *non-numeric* type related by inheritance] :Examples (*) and (**) are examples of "constrained genericity," which is :exactly what you said would be really nice to have. So you have it an :Eiffel AND Ada. No, I think Nick meant constraining from a common ancestor *through inheritance* which is different from the examples you have given. We already know that both Ada and Eiffel support both constrained and unconstrained genericity. :In Ada, you can even do mixin inheritance without using multiple :inheritance. Yes, through a round-about way using genericity. This is inelegant compared with multiple inheritance. However, it's simple compared to the obscure technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3. I'm still trying to comprehend that one! :Imagine that! Imagine! Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au