To: J3                                                     J3/19-135
From: Malcolm Cohen
Subject: Protected types and components
Date: 2019-February-11


1. Introduction

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

2. Protected types

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 type a "protected" type 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 type is somehow "protected".


3. Protected components

The primary use cases for protected components are the same as for
protected types, but when it is desired to allow some component of the
objects to be modified directly.  This can already be achieved within
the protected type framework by the module providing a "modifier"
procedure to do that.

The desirability of protected components thus hinges mostly on the
possible improved performance and clarity of direct modification.
Also, it is easier to add protection to part of a type by using
protected components, than it is to make the whole type protected
and retrospectively change the direct assignments to the components
(for which protection is not desired) into procedure references.


4. Formal requirements

4.1 For protected types

- that a derived type may be defined to be "protected";
- an object of protected type is not permitted in a variable definition
  context outside the module defining the type, except that it may be
  an actual argument corresponding to an INTENT(INOUT) dummy;
- the same rule applies to an object of unprotected type that has a
  subobject of protected type (not permitted in a variable definition
  context etc.);
- a subobject of an object of protected type is not permitted in a
  variable definition context or pointer association context outside the
  defining module;
- a pointer of protected type may have its pointer association changed
  outside the module, but not by deallocation as its target is protected.

4.2 For protected components

- 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.


5. Summary

It might be noticed that the requirements for a type with all protected
components are essentially the same as those of a protected type.  So only
one should be done.

Protected types are somewhat simpler than protected components, and gain
most of the advantages for new code at least, but are a little less
flexible especially when retrofitting to old code.

===END===