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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,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: 257023695 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: > Jon S Anthony wrote: > > :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. > > The convenience is there if you need it. You don't even have that > option in Ada. ??? Of course you do. That's what I meant by building a "Numeric" tagged type (speaking of reading/quoting things in overall context...). Of course, you do actually have to build it if you really want this and _that_ might be considered a disadvantage. > :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. > > Ditto. Ditto. > :> :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 your opinion. Right - as stated. The important point being that the contrary view is _just opinion_ as well. And IMO (:-), not at all convincing. Especially as there are loads of alternative modeling styles used everywhere everyday. > :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, > > Depending on who you listen to, that's an inappropriate use of MI. But _not_ of mixins. Which is exactly the point. > > :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. /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