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,988f2c34ce3e6595 X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Modest proposal, 2 of 3 Date: 1996/11/26 Message-ID: <329AA8DE.2CFC@lmtas.lmco.com>#1/1 X-Deja-AN: 200850221 references: <575ag6$rt6@netline-fddi.jpl.nasa.gov> <3299FA03.5A1D@watson.ibm.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.02 (Macintosh; I; 68K) Date: 1996-11-26T00:00:00+00:00 List-Id: Norman H. Cohen wrote: > > The effect of an object modifiable as a variable from within a package, > but only readable as a constant from outside the package, can already be > achieved in Ada 95 as follows: > > package P is > type Access_Constant is access constant Integer; > Constant_View_Of_Variable: constant Access_Constant; > private > Variable: aliased Integer; > Constant_View_Of_Variable: > constant Access_Constant := Variable'Access; > end P; > > Of course this doesn't quite achieve the referential transparency Van > Snyder is after, because it requires you to say > Constant_View_Of_Variable.all instead of Constant_View_Of_Variable. Myself, I prefer: package P is function Constant_View_Of_Variable return Integer; pragma Inline (Constant_View_Of_Variable); private Variable : Integer; end P; package body P is function Constant_View_Of_Variable return Integer is begin return Variable; end Constant_View_Of_Variable; end P; Van Snyder wrote: >> Thus, a variable that a package publishes with "out" mode has the same >> properties as a private variable with a public parameterless function to >> access it, and no procedure to update it directly. But it's more >> efficient, I write this sort of code all the time, and I promise any reasonable optimizing compiler will reduce this code to zero overhead, if that's the efficiency in question. >> and there's less code to write initially, and therefore less >> to read and understand when you're the poor schmo assigned to make the >> next minor change. "Less code to write" does not necessarily translate into "easier to read and understand." What you're really trying to do is separate the client's view of the object's representation from the underlying implementation. Your specific example involves separating the public view of a constant integer from the implementation view of a variable integer, or (to fix the .all problem) an implementation view of access to an integer. However, a few years down the road, I may just as easily want the public view to remain a constant integer, and the private view be a variable _fixed-point_ type. If the "poor schmo" is just using the public view of this object, he doesn't have to look any further than the spec to understand how to use the object. So, your proposal isn't helping him. If the "poor schmo" is maintaining the underlying representation, then your proposal _hurts_ him, since he'll have to do more work to maintain the public view of constant _integer_ while changing the underlying type to something else. More importantly, he'll probably end up changing the public part of the spec, which means every user of this object also has to change. Now, you've _really_ caused a maintenance problem. One other comment: What would the proposal mean with respect to accessing the global "out" variable via child packages? Would private children be able to write to the variable, for example? It would seem that the rules for child packages would be further complicated by this proposal. I think the existing Ada approach is much more flexible than the proposed solution. If writing these lines is really a burden, then get an editor that supports templates! -- LMTAS - "Our Brand Means Quality" For more info, see http://www.lmtas.com or http://www.lmco.com