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: 449704292 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev7 References: <7b6nqe$75m$1@remarQ.com> Organization: CSC Australia, Sydney Reply-To: nospam@thanks.com.au Newsgroups: comp.lang.ada Date: 1999-03-01T00:00:00+00:00 List-Id: Fraser wrote: :I nearly cried when nospam@thanks.com.au said: ^^^^^ ? :>What about "procedure Do_Something (S : access Singleton_Type)", to :>avoid a bunch of S.all's everywhere. :>:I just love the way Ada compilers fill in .all for me. : :>Can you give an example? : :Sure. This is an idiom I use all the time (well, until I wrote a generic dynamic :array package, but that's another story): : : type Array_Type is array (Positive range <>) of Integer; : type Array_Access is access Array_Type; : : X : Array_Access; : Y : Integer; : Z : Array_Type (1 .. Size); :begin : : X := new Array_Type'(1 .. Size); : : Y := X (3); -- same as X.all (3) : : Z := X.all; -- .all required here :end; : :Subprogram access types are similar. Okay, got you - the combination of formal access-parameters and implicit dereferencing means that no client should have to explicitly dereference. :Bertrand Meyer goes into this sort of thing :in his Eiffel book, but I can't remember the term he used. You know, the bit :about everything being accessed the same way, regardless of the underlying type. Yes, although I also forget his term for it. The little syntactic sugar Ada offers helps compensate for the more typical situation of enforced literal-ness. For example, having to bother with the difference between: - An object and a reference to it. - A tagged type and a 'class' rooted at that type. Given Ada's requirement for reliability, such literal-ness isn't surprising. It's also interesting to note that some of Eiffel's weaknesses are a result of glossing over such distinctions. :I think Eiffel (at least in its first incarnation, I haven't checked the language's :revision history) goes a little overboard in its race for purity (but that's another :article). That view seems to be widely held in Ada circles. However, I can't help noticing that purity very neatly deals with the singleton issue (.. and a number of other Ada problems). :) :Not having to worry about whether something's an array or an array access :when you index it is a small plus, but it's representative of a wider philosopher. Agree. -- Don (Harrison). donh at syd.csa.com.au