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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,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/15 Message-ID: #1/1 X-Deja-AN: 256953174 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-15T00:00:00+00:00 List-Id: 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. :> 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. Ditto. :> 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. Try reading the whole paragraph instead of quoting out of context - it's obvious I'm talking about inheritance ala tagged types. :> *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. Possibly. :> :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. :> :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, Depending on who you listen to, that's an inappropriate use of MI. :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. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au