Re: Modest proposal, 2 of 3

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

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