>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. :-)
Contrarian? Certainly not. Well, unless you said I wasn't yesterday,
in which case I was.
>> 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.
Yes, but preventing writing to a variable is not the only reason
to encapsulate (in my case, it's almost never the reason).
Now, I want to be clear here. I am not strenuously opposed to the
READONLY feature you describe (and the main reason I responded
is that my name was already included). I just believe that, by the time
the feature makes it into the language it will basically be redundant.
It is not complicated in it's meaning, nor is its implementation fraught
with difficulties for the compiler writer. It's just not something I'd
ever likely use.
Consider some of the other features that (I hope) will be in the standard
in about the same time-frame as you're talking about. The ability to
explicitly declare that a MODULE procedure *must* be inlined (or that
it must not be) should be in the standard by then. This means that, if
you explicitly declare the access function to be INLINEd, there will
definitely be no optimization advantages to the READONLY approach.
In addition, there is occasional mention of cleaning up the syntax of
function references. It would be a good idea if nullary functions (those
with no arguments) that have an explicit interface be referenced by
name only (without the need of an empty argument list). The empty
parenthesis are only required now because of the ambiguity between
an implicitly declared scalar and a function with implicit interface. It
the symbol has been explicitly declared, such an ambiguity doesn't
exist.
Given those two possible/likely features, your previous example would
look as follows:
!!! with READONLY:
INTEGER FUNCTION sub( j )
USE mod !!! mod contains INTEGER,READONLY :: i
IMPLICIT NONE
sub = j * i
END
!!! without READONLY -- an access function needed:
INTEGER FUNCTION sub( j )
USE mod !!! mod contains INTEGER,PRIVATE :: value_of_i,
!!! returned by INLINE function i
IMPLICIT NONE
sub = j * i
END
Notice that the difference is not even perceptable to the code that
USEs the MODULE except that the comments describe the difference
of internal operation.
--
J. Giles
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|