At 11:54 01-09-98 +0100, you wrote:
>The issue of READONLY again:
>
>There are actually two different but related attributes involved:
>
>a) visibility  as expressed by PUBLIC vs PRIVATE
>and
>b) modifiablity as expressed by READONLY vs WRITEONLY vs READWRITE
>
>PRIVATE doesn't need any of the modification attributes. That leaves
>   PUBLIC, WRITEONLY
>   PUBLIC, READONLY
>   PUBLIC, READWRITE
>
>PUBLIC, WRITEONLY doesn't make much sense to me (you can modify a variable
>but not directly use it afterwards except through a get function?).
>However, the READONLY case is much more common so it is worthwhile to give
>it extra attention. Two cases are left:
>PUBLIC, READWRITE (short form: PUBLIC) is the one we already have and
>PUBLIC, READONLY the one many of us want. Shortening this to READONLY is
>maybe not very pretty but is short and concise.
>

Think this is a useful addition to be included in Fortran.
I support you in the demand (suggestion ;-) ?) to put this on the
wish list with a priority level  7 (out of 10).


>(There are more possibilities and needs to refine access: The access
>attributes could take names that would give specific modules access to
>specific variables or procedures:
>
>   PRIVATE   equivalent to PUBLIC(NONE)
>   PUBLIC                  PUBLIC(ALL)
>   PUBLIC(A,B)             only access for modules A and B
>
>There are always cases in larger programmes where one would like to divide
>code into several different modules but still allow unrestricted access among
>themselves but not to others. Examples are easily found in libraries which
may
>want to share many things but do not want to grant an external user these
>privileges.)
>
>
>I agree with Peter Shenkin that READONLY is a good and practical way of
>achieving safety for data in modules. There are few cases where this
>functionality is not sufficient and where a get function can offer more.
>(The PRIVATE attribute is available here.) A compiler may inline the often
>trivial get functions and then no difference is left.
>
>And I want to stress that this applies to MODULE variables as well as
>TYPE components, esp. with regard to the new OOP facilities. We should
>not limit our considerations to modules only.
>
>When it comes to modifying code there are some problems. One may have
>to change a variable into a function for whatever reasons (typically a
>design error):
>a) the new function has no arguments. This could be solved by referential
>   invariance as Van Snyder has often suggested. This would avoid
>   invalidating old code.
>b) the new function needs arguments. Then there is no alternative but
>   to change existing code.
>
>But what about the other scenario where a function is no longer needed
>and some efficiency would be gained by moving towards a READONLY variable?
>A similar analysis applies.

No idea yet about the details and implications.




---
Meilleures Salutations,
Best Greetings,
/---
Jan van Oosterwijk
Computing Centre
Delft University of Technology
Postbus    354
2600 AJ  Delft
Netherlands / Pays Bas
Phone: +31 15 278 50 17
Fax:   +31 15 278 37 87




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%