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/01 Message-ID: #1/1 X-Deja-AN: 450168126 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev7 References: <7be1ou$mjg$2@plug.news.pipex.net> Organization: CSC Australia, Sydney Reply-To: nospam@thanks.com.au Newsgroups: comp.lang.ada Date: 1999-03-01T00:00:00+00:00 List-Id: Nick Roberts wrote: :I think, possibly, you're missing the point, Don! Yes, you're right. Sorry about that. What was missing was the ability to derive a class hierachy of singletons and dispatch on the exported objects. This is what I meant by: > 2) Are polymorphic Sorry if that wasn't clear enough initially. :Planet_Id is only an :identifier of a planet, not the planet itself. There is only one instance :of each planet -- kept in terms of variables within (the body of) each :planet package -- and the corresponding Planet_Id simply gives access to the :planet. It's just like having a single object with potentially many access :values pointing to it; I'm just using integers (type Planet_Id) instead of :access values. Got you. :Again, you must not confuse design with implementation: I'm using packages :here instead of types, and integers instead of access values. But these are :mere implementational details, and nothing to do with the design. The :design is: single objects (the planet packages); polymorphic access to them :(via planet ids and the package Dynamic_Planet). The 'objects' in our :design do not have to be objects in implementation (we use packages :instead); the 'access' values in our design do not have to be access values :in our implementation (we use integers instead). 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. :Hope this clarifies things. It does. -- Don (Harrison). donh at syd.csa.com.au