Separation of scopes and objects

[aardvark179]

I'm creating this issue to track the things I know of which need to be tackled to separate objects and scopes in our implementation.

Separating scopes and objects

Future performance optimisations become significantly easier when we can separate the concepts of scopes and objects. Specifically it makes traversal through parents one dimensional rather than two dimensional as scopes do not have prototypes and objects to not have parents (at least not in way that should ever be important when resolving a property).

To separate the concepts of scopes and objects in Rhino without disturbing too many APIs it would be useful to preserve a few things.

1. We would like to keep the existing APIs on Scriptable which define property access in terms like Object get(String name, Scriptable start). Crucially the start argument when looking up a property on an object must always be an object.
2. We would like our new scopes to offer a similar API like this: Object get(String name, Scope start). Again, the start argument when looking up something on a scope should always be a scope.
3. We would like to be able to use the same underlying property / slot map implementation. That means that either this implementation must duplicate methods to provide tow versions of each method, and this must also happen on various slot definitions, or we need to do something with parameterised types in order to preserve our guarantees.
4. Pretty much any solution that satisfies points 1. to 3. prevents us from having objects that are both scopes and objects.

My proposed way to handle this is with the following type hierarchy:

• SuperType<T extends SuperType<T>> (SuperType is chosen as a deliberately bad name here, we can discuss what it should actually be called at a later date).
  • Scriptable extends SuperType<Scriptable>
  • Scope extends SuperType<Scope>

This allows a large number of uses of property access and definition to remain unchanged, especially in user code, and requires simple modification of our slot map code. It also prevents us form accidentally (or purposefully) passing a scope as an object or an object as a scope, but all of this is at the price of not having objects which are both scopes and objects.

Since Scopes only ever have name bindings we could theoretically make the super type handle those, but we might reasonably use symbol properties for internal data, and the interface is simpler if the two halves of the hierarchy are the same.

There are other small differences between the two halves of the hierarchy. Scopes have parents, while objects have prototypes, but a parent is of a scope is always a scope, and a prototype of an object is always an object, so they are really a common operation that can be written as T getAncestor().

So, what problems do we need to resolve to make this separation achievable?

TopLevel is both a scope and an object (#2164)

Because TopLevel fulfils all the roles mentioned earlier, it is currently a scope and an object and we need to separate those two parts (as the spec does). TopLevel will not present any significant optimisation issue because, although it is a scope it never has a parent and can effectively delegate to the prototype chain of the global object. We have also allow initialisation of a context on any ScriptableObject, but this requires checks in several places to check if the scope is a TopLevel, and leads to subtle bugs with prototypes which should only be defined as intrinsics and are not exposed on the global object. Maybe we should shift to insisting the scope is a TopLevel but allowing for a custom global object.

with scopes

We use with scopes in a few places, often mostly unnecessarily. They are a scope which holds an object as its prototype and delegates to that object. They present a significant optimisation barrier as lookup must be done on the object's prototype chain, and then on the parent scope chain. Hence, although they should be supported (even though they are deprecated) we should endeavour to refactor way from their use wherever possible.

__parent__ property

__parent__ is no longer in the specification, and for good reason as it captures and gives direct access to scope objects in ways that allow for bad resource leaks and can break many implementation assumptions. However a small amount of code in the wild may still this feature, and to support that we should be able to wrap a scope in an object that is effectively the reverse of with. This object should likely be intentionally limited to prevent any attempt to manipulate the prototype chain or define accessor properties. I have not found any code that relies on mutating __parent__ after an object has been created, and we should likely not support that.

Custom module systems

Any custom module system which has a name space concept will likely either need to make those scopes with scopes, or must do something similar to __parent__. The former approach would likely present larger optimisation issues.

Avoid setting of parent scope on objects

We should be able to avoid setting parent scope on almost all objects. The exception is function objects whose parent scope is their declaration scope, and we have already separated that concept at the interface level. We can start to enforce that parent scope is not set unless __parent__ is required.

[aardvark179]

Okay, I think I'm starting to zero in on a set of commits that do this and could be turned into PRs. I've tried to set myself some strong criteria for:

1. No PR should be bigger than about 500 added / 500 lines deleted.
2. The larger the PR the more purely mechanical the change should be. If we mix behavioural changes in with large mechanical changes then it's easy to miss them, and it's harder to discuss those aspects in isolation.
3. We want to end up with full separation of scopes and scriptable objects, and for this to be reflected in the call and construct APIs, but we also want to limit the blast radius of this so want to change as few APIs as possible.

Let's approach this by at where we are, where we want to get to, and what constraints we have on our path.

Laying some groundwork in the type system

Currently the types we are concerned with in Rhino have a hierarchy like this:

graph TD
    classDef Interface stroke:DeepSkyBlue,color:DeepSkyBLue;
    classDef Concrete stroke:Orange,color:Orange;
    Others["3rd party classes"]
    ScriptableObject
    SlotMapOwner
    Scriptable
    ScriptableObject ---> Scriptable
    ScriptableObject ---> SlotMapOwner
    Others ---> Scriptable
    class ScriptableObject Concrete
    class SlotMapOwner Concrete
    class Scriptable Interface
    class Others Concrete

Loading

We want to get to something like this as our end point:

graph TD
    classDef Interface stroke:DeepSkyBlue,color:DeepSkyBLue;
    classDef Concrete stroke:Orange,color:Orange;
    Others["3rd party objects"]
    ScriptableObject
    ScopeObject
    Scopes["3rd party objects"]
    SlotMapOwner
    Scriptable
    VarScope
    ScriptableObject ---> Scriptable
    ScriptableObject ---> SlotMapOwner
    Others ---> Scriptable
    ScopeObject ---> VarScope
    Scopes ---> VarScope
    class ScriptableObject Concrete
    class SlotMapOwner Concrete
    class Scriptable Interface
    class Others Concrete
    class ScopeObject Concrete
    class Scopes Concrete
    class VarScope Interface

Loading

But there's a couple of problems. Firstly trying to do all this change at once produces a gigantic PR, and all our existing code for handling properties internally is using slot maps help on SlotMapOwner, so we actually need something more like:

graph TD
    classDef Interface stroke:DeepSkyBlue,color:DeepSkyBLue;
    classDef Concrete stroke:Orange,color:Orange;
    Others["3rd party objects"]
    ScriptableObject
    ScopeObject
    Scopes["3rd party objects"]
    SlotMapOwner
    Scriptable
    VarScope
    ScriptableObject ---> Scriptable
    ScriptableObject ---> SlotMapOwner
    Others ---> Scriptable
    ScopeObject ---> VarScope
    ScopeObject ---> SlotMapOwner
    Scopes ---> VarScope
    class ScriptableObject Concrete
    class SlotMapOwner Concrete
    class Scriptable Interface
    class Others Concrete
    class ScopeObject Concrete
    class Scopes Concrete
    class VarScope Interface

Loading

and we'll need an approach that works towards that in small steps.

But, again, we hit a problem, most of the slot access logic is on ScriptableObject, and the API is littered with references to Scriptable. So we need to make this more generic without disturbing existing uses of the API, and move logic to SlotMapOwner where we can reuse it. We can approach this in two parts, firstly we can change the class hierarchy like this:

graph TD
    classDef Interface stroke:DeepSkyBlue,color:DeepSkyBLue;
    classDef Concrete stroke:Orange,color:Orange;
    ScriptableObject
    SlotMapOwner["SlotMapOwner<T>"]
    Scriptable
    PropHolder["PropHolder<T>"]
    ScriptableObject ---> Scriptable
    ScriptableObject --T = Scriptable--> SlotMapOwner
    SlotMapOwner ---> PropHolder
    Scriptable --T = Scriptable--> PropHolder
    class ScriptableObject Concrete
    class SlotMapOwner Concrete
    class Scriptable Interface
    class PropHolder Interface

Loading

This change causes about 500 insertions and 450 deletions because we are forcing the entire SlotMap interface to be generic, but crucially we maintain a single concrete type at the Scriptable interface and the ScriptableObject class so the blast radius is limited to the classes related implementing to slots and slot maps>

We can then hoist many functions from ScriptableObject to SlotMapOwner, making them generic on <T>. This is another fairly large change due to the number of methods involved, but only affects those two classes so has a very limited blast radius.

These changes provide a firm foundation to start building and using our new scopes, but to avoid sudden large changes we aren't going to build them in their final form separate from Scriptable, our aim is to minimise the pain at each stage.

Building our scope objects in the hierarchy

We can start build scope objects as a subtype of Scriptable as follows:

graph TD
    classDef Interface stroke:DeepSkyBlue,color:DeepSkyBLue;
    classDef Concrete stroke:Orange,color:Orange;
    ScriptableObject
    ScopeObject
    SlotMapOwner["SlotMapOwner<T>"]
    VarScope
    Scriptable
    PropHolder["PropHolder<T>"]
    ScriptableObject ---> Scriptable
    ScopeObject ---> VarScope
    VarScope ---> Scriptable
    ScriptableObject --T = Scriptable--> SlotMapOwner
    ScopeObject --T = Scriptable--> SlotMapOwner
    SlotMapOwner ---> PropHolder
    Scriptable --T = Scriptable--> PropHolder
    class ScriptableObject Concrete
    class ScopeObject Concrete
    class SlotMapOwner Concrete
    class VarScope Interface
    class Scriptable Interface
    class PropHolder Interface

Loading

This, again, causes a few hundred lines of change but I think that can be reduced significantly.

The reason for choosing this particular hierarchy is that it allows all the signatures of call and construct and similar to continue using Scriptable as their type (because VarScope is a subtype of Scriptable) but allows us internally to start separating scopes from ScriptableObjects.

Adopting the use of ScopeObject across our runtime and tests results in about 400 insertions and 400 deletions, roughly 75% in the runtime itself, and the remainder being small changes to tests needed to change some variables to be VarScopes rather than Scriptable.

Changing our public API signatures

Changing our call and construct is likely to have to be multi stage process. Any explicit subclassing implementation of these methods must have a type signature that precisely matches the method, but any method reference with wider argument types and a narrower return type can be coerced by the compiler to Callable or Constructable. So we first change the scope arguments on call and construct to be a Varscope (narrowing that type). This causes about 300 lines of insertion, and 300 deletions.

We can then move all our lambda based JS methods to match that new signature. This causes about 400 insertions and 600 deletions (the difference being due to this pushing a lot of methods declarations just under a line length limit and causes reformatting).

One that is tightening up all the internal types causes another 300-400 insertions and deletions.

Final separation of types

Final separation of VarScope and Scriptable does require another few hundred lines of fixing types, and it hits a couple of speed bumps with our this lookup and a few other bits. I'm not going to start making these PRs unti I've got those issues ironed out and pulled into separate PRs that can be done earlier in the process.

I've also found a couple of issues around FunctionObjects and native Java classes, __parent__ properties, and some native Java wrapping code. None of these seem to be a major issue, they just require that we keep getParentScope() for now.