Semantics of an empty PermittedSubtypes attribute for the VM
John Rose
john.r.rose at oracle.com
Fri Apr 3 22:12:16 UTC 2020
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.
More information about the amber-spec-experts
mailing list