[J3] [EXTERNAL] Private enumerators

[Reuben D. Budiardja]

On 10/25/19 2:40 PM, Clune, Thomas L. (GSFC-6101) wrote:
> My opinion is that any behavioral changes inside vs outside are making this feature far too complex.   I’d rather have no PRIVATE/PUBLIC option at all than to risk not iterating over all members.

Another possibility is to have different procedures that are only 
accessible inside the module (i.e. "private" procedure) in addition to 
NEXT() and LAST, for example: TRUE_NEXT() and TRUE_LAST (obviously need 
better names but I can't think of any at the moment).

> Instead, I’d rather put enum extensions back on the table.    Then the “public” components could be in the base enum types, and the extension type (and its members ) could be private.    I think this handles the use cases while also making the feature more usable in other contexts (esp. generics).

I am also in favor of having ENUM extensible. And yes, I agree on these 
points.

Best,
Reuben

> - Tom
> 
> 
> 
>> On Oct 25, 2019, at 2:25 PM, Reuben D. Budiardja via J3 <j3 at mailman.j3-fortran.org> wrote:
>>
>> Hello,
>>
>> On 10/19/2019 01:37 PM, Van Snyder via J3 wrote:
>>> Gary objected to private enumerators.
>>> Access specs control access to identifiers, not objects.
>>> He didn't like the possibility that one might be able to get the value
>>> of an enumerator for which the module did not publish the name, using,
>>> for example, INT(foo)+1 or foo%next().
>>
>> I share the concern regarding access to private enumerators. Being able to get the ordinal value of a private enumerator with NEXT() and turn it back using the constructor seems to defeat the point of the enumerator being private, and therefore a vulnerability.
>>
>> For example, suppose enumerators are being used to identify some state, then being able to iterate over the private enumerators with foo%next(), one can deduce how many (internal) states there are, and perhaps use this state as argument, etc, introducing vulnerability.
>>
>> I think it also defies "regular user's" expectation. I understand that we say ENUM is not derived type and enumerators are not component, but some similarities hold. With PRIVATE component, there is no access to the name or value of the component outside the module unless explicitly given, e.g. via getter and setter subroutines in the module. With ENUM as proposed, this is effectively provided and there is no way to disable it.
>>
>> I was thinking perhaps a solution is to require that all private enumerators to be defined after the public one, so that the ordinal values for private enumerators are always higher than the public one. Then, the requirements could be that NEXT() inside the module would traverse all the enumerators, while outside the module would only traverse the public enumerators. The same thing with LAST().
>>
>> Some examples:
>>
>> Example 1:
>>
>> enum, public :: color
>>   enumerator, public  :: red, green
>>   enumerator, private :: purple   ! <-- compile error,
>>                                   ! require all private after public
>>   enumerator, public  :: blue
>> end enum
>>
>>
>> Example 2:
>>
>> module enum_def
>>
>>   enum, public :: color
>>     enumerator :: red, green, blue
>>     enumerator, private :: purple, black
>>   end enum color
>>
>> ...
>>
>>   type(color) :: my_car = color%blue
>>   my_car%last !-- would give "black"
>>   my_car = my_car%next() !-- would give purple
>>
>> end module enum_de
>>
>>
>> module my_object
>>
>>   use enum_def
>> ...
>>   type(color) :: my_house = color%green
>>   my_house%last !-- would give "blue" since this is
>>                 !   the last of the public enumerator
>>
>>   my_house = my_house%next()  !-- would give blue
>>   my_house = my_house%next()  !-- ERROR terminated
>>
>> end module my_object
>>
>>
>> End examples.
>>
>>
>> I would be interested in feedback.
>>
>> Best,
>> Reuben
>>
>> -- 
>> Reuben D. Budiardja, Ph.D.
>> reubendb at ornl.gov | (865) 576-9519
>> National Center for Computational Sciences
>> Oak Ridge National Laboratory

-- 
Reuben D. Budiardja, Ph.D
reubendb at ornl.gov | (865) 576-9519
National Center for Computational Sciences
Oak Ridge National Laboratory