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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID 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: "Nick Roberts" Subject: Re: Can't export object of private type Date: 1999/03/01 Message-ID: <7be1ou$mjg$2@plug.news.pipex.net>#1/1 X-Deja-AN: 449932231 References: <7b8cvc$ii5$3@plug.news.pipex.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.ada Date: 1999-03-01T00:00:00+00:00 List-Id: I think, possibly, you're missing the point, Don! 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. 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). Or is it me who is missing the missing the point? :-) Hope this clarifies things. ------------------------------------- Nick Roberts -------------------------------------