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,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public From: jsa@alexandria.organon.com (Jon S Anthony) Subject: Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Date: 1997/07/15 Message-ID: #1/1 X-Deja-AN: 256887760 Distribution: world References: Organization: PSINet Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-15T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > 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 Who cares. In typical practice this is not even going to be used - the efficiency sucks for any real numerical work and you will have to resort to expanded types anyway. > 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. Shrug. If you want that, just build Numeric. But really, I doubt that this is something you will want in the sort of applications Ada and Eiffel target. You want this sort of stuff? Use CL. > 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 False. You can extend and change the _behavior_ through inheritance. > *other* inheritance mechanism - derived types - but that doesn't allow > polymorphism so you miss something compared with Eiffel. Right. As for polymorphism here - again who cares? as it is not very likely that you want dispatching on individual numbers anyway. > :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* OK, but again - who cares? IMO, forcing everything into a classification style of model naive, simplistic, overly constraining, and typically wrong. > :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. No it is not. IMO, for mixins, the generic + SI is a _much_ better model as it does not confuse the issue with any sort of is-a semantics. Just because I want to mixin a printing capability with my rational number facility, does not mean that my rational numbers suddenly become printers, but with MI, that is basically what you are saying even though you probably don't mean it. What you are really looking for with mixins is composition with a form of automatic delegation. > 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! It is obscure, but not particularly difficult. However, I agree that is the one case where MI is actually useful. OTOH, this is relatively rare thing. IMO, if you really want/need this level of capability, then you may as well just use CLOS, as it is far more capable than either Ada's or Eiffel's object model. /Jon -- Jon Anthony OMI, Belmont, MA 02178 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari