(j3.2006) Absurdity concerning the PROTECTED attribute.

[Bill Long]

Yeah, I agree that PUBLIC and PRVATE are different, since they can be used to override an existing attribute of an object (similar to  VOLATILE and ASYNCHRONOUS).   I usually think of these as ?access specs? rather than attributes, so didn?t include them.  But technically they are attributes.

Cheers,
Bill


On Mar 30, 2015, at 5:03 PM, Tom Clune <Thomas.L.Clune at nasa.gov> wrote:

> I think you have to allow PUBLIC as well.  Aside from stylistic reasons that I like, there is this issue:
> 
> PRIVATE
> PUBLIC :: bar
> 
> interface bar
>    module procedure newBar
> end interface
> 
> How does one keep the specific name private while making the generic name public without an attribute statement?
> 
> - Tom
> 
> 
> 
> 
> 
> On Mar 30, 2015, at 5:44 PM, Bill Long <longb at cray.com> wrote:
> 
>> 
>> I would be quite happy to get rid of (at least make obsolete) most of the attribute statements, including PROTECTED.  Only VOLATILE and ASYNCHRONOUS serve any useful purpose anymore.  If we did not have a PROTECTED statement, this problem would not arise. 
>> 
>> Cheers,
>> Bill
>> 
>> 
>>> end module m2
>>> 
>>> module m3
>>> contains
>>> subroutine S3
>>>   use M1, only: I
>>> ! use M2, only: I
>>>   i = 666
>>> end subroutine S3
>>> end module M3
>>> 
>>> Is I definable in subroutine S1 in module M1?  5.3.15p2 says not.  This
>>> is absurd.  How about in subroutine S3 in M3?  Definablilty depends upon
>>> which USE statement is not a comment.  This seems to be nearly as
>>> equally absurd.
>>> 
>>> This begs for an interp.
>>> 
>>> Should it be prohibited to confer the PROTECTED attribute upon an entity
>>> that is accessed by use association, or should 5.3.15p2 be revised:
>>> "Where an entity is accessed by use association, if it has the PROTECTED
>>> attribute in the module from which it is accessed then...?"  The former
>>> is simpler, and seems more sensible than the inconsistent alternative,
>>> i.e., allowing or prohibiting definabililty in S3 depending upon whether
>>> I as accessed from M1 or M2.
>>> 
>>> I'll write an interp, but it would be nice to have consensus regarding
>>> on which side of the court the ball will drop.
>>> 
>>> 
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at mailman.j3-fortran.org
>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> 
>> Bill Long                                                                       longb at cray.com
>> Fortran Technical Suport  &                                  voice:  651-605-9024
>> Bioinformatics Software Development                     fax:  651-605-9142
>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Thomas Clune, Ph. D. 				<Thomas.L.Clune at nasa.gov>
> Head ASTG,Code 606
> NASA GSFC		
> MS 610.8 B33-C128
> Greenbelt, MD 20771
> 301-286-4635
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101