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.3 required=5.0 tests=BAYES_00,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: Matthew Heaney Subject: Re: Can't export object of private type Date: 1999/03/10 Message-ID: #1/1 X-Deja-AN: 453305996 Sender: matt@mheaney.ni.net References: NNTP-Posting-Date: Tue, 09 Mar 1999 23:53:57 PDT Newsgroups: comp.lang.ada Date: 1999-03-10T00:00:00+00:00 List-Id: nospam@thanks.com.au (Don Harrison) writes: > :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. If you need to compute the product of X and Y, there's nothing in the language that forces you to write the expression X * Y either! > 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. There is no requirement for a main program in Ada95. (Although I must admit I've never actually tried to write an Ada95 without one.) > The "ugly stuff" is not the result of lax design. It is the result of failing to encapsulate low-level data (an array) behind a higher-level abstraction (a collection with iterator). It is the same as if you had written type Integer_Stack is record Items : Integer_Array; -- can this ugly stuff be omitted? Top : Natural := 0; end record; Yes, of course the ugliness can be omitted -- by hiding it. > It's caused by the fact that Ada requires explicit syntax to represent > the notions of class membership ("'Class") and referencing ("access"). No. You declared a collection object as an unencapsulated array, and then complained that it was ugly. (And I agree with you.) The language gives you tools to remove the ugliness, by hiding it behind an abstraction (in this case, a collection abstraction implemented as a state machine). > You can hide that syntax from clients, as you suggest, but that isn't > the same as removing it. No one is saying you can eliminate the array; there has to be an array somewhere. All I'm advocating is that you declare the array in the package body, and visit the items in that array via an iterator. I'm viewing the array at a higher level of abstraction. I'm saying that what you have is a collection of singletons, which happens to be implemented as an array. The array is strictly an implementation detail, that we both agree is ugly.