I should know better than to take Jim Giles' name in vain. :-)
I'm tempted to say something like "always the contrarian"; he
would probably disagree, but perhaps that's what I mean. :-)
On Aug 31, 12:24pm, James Giles wrote:
...
> Consider Peter Shenkin's example quoted above. Suppose that
> the MODULE is altered so that the variable I is no longer explicitly
> stored, but must be computed from other PRIVATE data in the
> MODULE. Program units which access the data only though the
> access function needn't be changed (though possibly they'd need
> to be recompiled). Program units which access the variable directly
> using the READONLY capability must be rewritten.
Indeed.
> It seems to me that if you find yourself in need of defeating encapsulation
> (like C++ "friend functions") or partially defeating it (READONLY
> attrribute), you should really be reconsidering what it was that you
> thought encapsulation was doing for you. Maybe the data shouldn't
> have been encapsulated in the first place.
...
Well, if all you want to do is to prevent USE-ing code from
changing the value of the variable, making it READONLY doesn't
defeat encapsulation any more than does providing a "get"
function.
This does raise a related issue that has, from time to time,
troubled me. Languages, like F90 and C++, that go to great
lengths to make things that are complicated underneath look just
like simple things to the user have the problem that the user
may not always know when he's doing something complicated.
For example, operations using array sections may, in certain
cases, be far less efficient than operations which appear
syntactically similar but which use simple arrays.
Despite the fact that this makes life easier for the user in
some ways, at the same time it makes it harder for the user to
realize when he is doing something that is likely to be
inefficient. It requires greater sophistication on his/her
part.
There are certainly things like this in F77 (such as accessing
the elements of a 2D array in row-major, rather than
column-major order), but they are fewer in number.
I concede to being of two minds about this. I like the economy
of expression that the newer paradigms embody, but I'm always
scared of inadvertantly coding something stupid.
To the extent that all that is being done is using a variable as
it it were READONLY, one advantage of READONLY over a "get"
function is that the former makes it clearer what is actually
being done. Yes, as Jim states, the code will then have to be
rewritten if the MODULE evolves so that a computation is
required, but this can also be seen as a virtue, because at
least then the user has some syntactical indication of the
fact.
Of course, since "=" can now be carried out by a user-defined
SUBROUTINE, even that indication can be misleading. Still,
despite Jim's points, I like the idea of READONLY PRIVATE
variables. His points regarding inlining are good ones, but I
don't think READONLY breaks encapsulation; it just provides a
different mechanism -- one just as safe as a "get" function
-- to query PRIVATE data.
-P.
--
**************** "Cultured people are the scum that floats ****************
*************** on the deep river of production" (Churchill) **************
*Peter Shenkin; Chemistry, Columbia U.; [log in to unmask] (212)854-5143*
*MacroModel WWW page: http://www.columbia.edu/cu/chemistry/mmod/mmod.html *
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|