Semantics of an empty PermittedSubtypes attribute for the VM

[John Rose]

On Apr 3, 2020, at 2:42 PM, forax at univ-mlv.fr wrote:
> 
> And more generally,
> should the VM offer a way to update the permitted subtypes list dynamically ?

To me that’s an easy “yes”, in the setting of HCs at least.
Here’s the reasoning:

- A HC can be dynamically injected into a nest, by invitation only.
- The purpose of this is to allow any nest to invite additional private actions.
- This allows us to defer building of bridges and adapters to runtime.

- A “private action” is any action which the static compiler could have arranged for.
- Private actions define encapsulation boundaries.  (They can be made public, protected, etc.)
- A private action can be (wait for it…) access to private members.

But a private action (as defined here) can also depend on other access
control mechanisms besides literal ACC_PRIVATE checks, as long as
they are associated with the job of the static compiler to create and
protect encapsulation boundaries.

Therefore:

- Given a Lookup with full powers on some nest N, a HC can be created which behaves as if it were on the permits list of any member of N.

Or, what’s to the same effect (assuming seamless teleports within a nest):

- Given a Lookup with full powers on some type C, a HC can be created which behaves as if it were on the permits list of C.