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: 103376,772ae8afc5db35f2 X-Google-Attributes: gid103376,public From: nospam@thanks.com.au (Don Harrison) Subject: Re: Can't export object of private type Date: 1999/03/04 Message-ID: #1/1 X-Deja-AN: 451069135 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev7 References: <7bjihr$25t7@news1.newsguy.com> Organization: CSC Australia, Sydney Reply-To: nospam@thanks.com.au Newsgroups: comp.lang.ada Date: 1999-03-04T00:00:00+00:00 List-Id: Sam Mize wrote: :Don Harrison wrote: :> Matt Heaney wrote: : :> :If you know up front how many "instances" of an abstraction you have :> :--what I call the "well-known objects" pattern-- then a state machine :> :package is probably the way to go. :> :> Partitioning objects into "well-known" and less-well-known :) will always :> be somewhat arbitrary. : :Perhaps a clearer term would be "enumerable" if this kind of confusion is :going to occur. It doesn't seem arbitrary to me that either you can list :all the objects up front, by their nature, like the planets -- or not. I think you're right that this kind of abstraction usually is enumerable but the property which suggests their implementation as a state machine is that their underlying behaviour is well-defined and isn't expected to change. This quality obviates the need for an explicit derivable type. The problem, of course, is that you're relying on foresight in anticipating no future requirement for variants. We can forsee future needs to some extent but not perfectly. :>However, in the context of non-pure OOPLs (such as :> Ada), you're probably right in suggesting it's worth distinguishing between :> single-fixed-variant (your "well-known") objects and more general ones. :> The additional flexibility gained in declaring an explicit derivable type :> is a waste of time if future variants are unlikely. : :Is it not a waste of time in an OOPL, or is it not possible to avoid :doing it in an OOPL? (That sounds confrontational and I apologize, but :I can't think of a better way to phrase it.) A decent pure OOPL (such as Eiffel) will leave open the possibility of deriving variants. Eiffel doesn't give you a choice - every class can have heirs, although you can freeze particular primitive operations if you choose. The downside is a loss of execution speed - roughly 15% of dispatching calls aren't optimised to non-dispatching calls (Gnu Eiffel). :> :In a typical Ada application, some abstractions are implemented as state :> :machine packages, and some abstractions are implemented as instances of :> :an abstract data type. There is nothing odd or unnatural about this. :> :> It's certainly idiomatic. : :Does you mean this to counter Matt's statement? No. I mean to agree that it's idiomatic - even if I disagree with the philosophy leading to the idiom. :) Ada allows you to choose the degree of reusability for abstractions. Many Ada developers exercise that choice and choose lower reusability and that may be reasonable for abstractions that have little prospect of changing. I prefer to err on the side of more reusability .. which inevitably makes my code less idiomatic. :If a language forces you :to use just one or the other, you would, and that would be idiomatic too. Certainly - for example, idiomatic Eiffel maximises derivability. :I'm not sure what you're trying to get across. Agreement with the expressed facts without disagreeing with the underlying philosophy that leads to them. :) -- Don (Harrison). donh at syd.csa.com.au