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/03 Message-ID: #1/1 X-Deja-AN: 450628186 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev7 References: Organization: CSC Australia, Sydney Reply-To: nospam@thanks.com.au Newsgroups: comp.lang.ada Date: 1999-03-03T00:00:00+00:00 List-Id: Matt Heaney wrote: :nospam@thanks.com.au (Don Harrison) writes: : :> Sure. What I'm trying to acheive is a set of implementation techniques for :> OO design that: :> :> a) Are consistent at least from the perspective of client code. :> For example, everything that is an object (including singletons) :> *looks like* an object (and not a module). :> b) Map as directly as possible from the design. :> c) Are idiomatic Ada. : :The state machine package is "idiomatic Ada." Your a) and c) goals may :be in conflict. Where possible, and where it makes sense, I want to leave open the possibility of reuse by inheritance as well as aggregation. Simple state machines won't allow this flexibility. :As I have argued in previous posts, don't export a singleton instance of :a type unless you have a compelling need to. Types should really only :be used to implement an abstraction that has an unbounded number of :instances. : :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. 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. [Matt's example] :An abstract data type wouldn't buy you very much except syntactic :overhead. Agree. :Thinking in terms of packages (or "modules", if you prefer that term) is :fundamental to Ada programming. If you're using singleton instances of :types everywhere, motivated perhaps by some notion of "purity," then :that may be a sign that you're fighting the language. :) :) :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. -- Don (Harrison). donh at syd.csa.com.au