To: J3                                                     J3/19-135r1
From: Malcolm Cohen
Subject: Protected components
Date: 2019-February-12


1. Introduction

This paper describes some use cases for protected components.
An attempt is made to elucidate the formal requirements.

The previous revision of this paper also described protected types.
Protected components provide a superset of that facility and therefore
only protected components are described here.


2. Protected components

2.1 Traversing a "protected" data structure

Assume a collection of data that are connected by pointers; for example,
a linked list or a tree.  There may be many places in a program that
traverse the data structure, using local pointers.

Even if the "head" of the data structure is given the PROTECTED attribute,
the data structure is mostly unprotected against accidental modification.

The current solution for protecting such a structure is to make all access
to it go through procedures (by having the linkages private).  This is
itself somewhat expensive, and adding such protection to previously
existing code can be very expensive as all the places that do traversal
must be found and modified.

Some way of permitting such traversal without permitting modification, and
without requiring massive changes to existing code, would be advantageous.
The suggestion is that making the components of the type "protected" would
solve this.

2.2 Data structures with large data objects

Assume a data structure which is a collection of large data objects.
For robustness this structure might always be accessed by "setter" and
"getter" procedures.

However, when the data objects are large, it would be useful for the
"getter" procedure to be able to return a pointer to the actual object
within the structure, rather than a copy of its value.  However, this
would not be safe unless the components of the type are "protected".

2.3 Data structures that are partly protected

In some cases part of the data structure require protection (for example,
the pointer components that make up the linked list) but for other parts
there would be no problem with modification outside the module.

Allowing some components to be protected and some to be unprotected allows
the improved clarity of direct modification for the unprotected components
(and possibly improved performance from not needing to invoke a procedure).


3. Formal requirements

- that a component may be defined to be "protected";
- such a component, or a subobject thereof, is not permitted in a variable
  definition context or a pointer association context outside the module
  containing the component definition;
- an object that has a protected potential subobject component is not
  permitted in a variable definition context outside the module, except
  that it may be passed as an actual argument corresponding to an
  INTENT(INOUT) dummy;
- a pointer to an object that has a protected potential subobject
  component may have its pointer association changed, but not by
  deallocation, and its target is still subject to the rules above.

===END===