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/10 Message-ID: #1/1 X-Deja-AN: 453285427 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-10T00:00:00+00:00 List-Id: Matt Heaney wrote: :nospam@thanks.com.au (Don Harrison) writes: :> function Solo_T return Access_Class_T_Type is abstract; : :I don't understand why you declared function Solo_T as abstract. It is :not a primitive type for T_Type. : :Even if it weren't abstract, why do you need it there in the root :package? All the (singleton) instances live in child packages. See my response to Nick. :> type Access_Class_T_Child_Type is access all T_Child_Type'Class; :> :> function Solo_T return Access_Class_T_Child_Type; : :Why does Solo_T return a pointer to a class-wide type? You want to have :a function that returns a pointer to the _specific_ type, because you're :pointing to an object of that type. You're probably right. :There's no need for dispatching, so return the specific type: : : type T_Child_Access is access all T_Child_Type; : : function Solo_T return T_Child_Access; Perhaps not. But, there *is* a need to force derivations to provide an access function ..which apparently Ada can't give us. :> type T_Index_Type is new Integer range 1 .. 2; :> type T_Array_Type is array (T_Index_Type) of Access_Class_T_Type; :> :> T_Array: T_Array_Type := ( :> 1 => T.Child.Solo_T.all'Access, -- 1) :> 2 => T.OTher_Child.Solo_T.all'Access); -- 1) :> 1) Can this ugly stuff be avoided? : :Yes. : :What you did here was to declare some data (an array of pointers to :singletons) outside of any object, and perform an operation on that data :(display each object). : :This isn't in the spirit of the object-oriented paradigm, in which data :is encapsulated by an object, and you send the object a message to :operate in that data. Your implementation is just the opposite, and the :symptom is "ugly stuff." Small nit.. The OO paradigm says nothing about sending messages. Although many people use this terminology (from dynamically-typed OOPLs), it's better to speak of dispatching calls in the context of statically-typed OOPLs. The use of the main program as a client has more to do with a desire to simplify the example while satisfying Ada's requirement for a main program than indicating a design preference on my part. The "ugly stuff" is not the result of lax design. It's caused by the fact that Ada requires explicit syntax to represent the notions of class membership ("'Class") and referencing ("access"). In many OOPLs, these details are implicit rather than explicit, thus relieving the developer from having to represent them explicitly. Ada has always had a literal approach to typing syntax and semantics and this philosophy has been preserved in its OO typing. Hence, explicit syntax is used to distinguish between: - Objects and references to them. - Specific and classwide types. You can hide that syntax from clients, as you suggest, but that isn't the same as removing it. :A better way to think of this problem is that you have a (singleton) :collection object containing (pointers to) all the singleton instances :in your type hierarchy. .. Agree. :Now, here's where we get back to our state-machine paradigm: the :subsystem rooted at package T _is_ the collection object. This would be the wrong way to model it, IMO. An object and a collection of them should be separate abstractions. : pragma Elaborate_Body; This is a welcome addition to Ada. It gives what the default semantics should have been from the beginning. :Each time Register is called, it increments the Last index, and inserts :the item into the array. (You don't have to worry about synchronization :issues, because elaboration is linear.) Right. -- Don (Harrison). donh at syd.csa.com.au