Representation of functions and signatures of `Callable` and `Constructable`.

[aardvark179]

We have a few closely connected bugs and features that are hard to implement in compliance with the spec due to our signatures for Callable, Constructable. The problems are essentially as follows:

1. Callable specifies thisObject as Scriptable but this is not entirely compatible with strict mode in the spec. We fudge it at the moment by handling undefined specially, but there's still a bunch of test cases where we fail on object equality and similar.
2. Constructable has no way to represent new.target which is needed for classes and inheritance.
3. Functions tend to conflate the function object and the executable thing that ends up being run (see bug Compiled functions and prototypes #1904).

There is also an issue that scopes probably shouldn't be full Scriptables, but this is currently required for with.

Fixing these issues causes widespread, but largely mechanical, changes to be required within our code base, but they are likely to be very minimal out side of it. I would propose fixing them roughly as follows

1. Introduce a super interface of Scriptable called Scope.
2. Redefining Constructable as follows:

public interface Constructable {
    Scriptable construct(Context cx, Scope scope, Object newTarget, Object[] args);
}

newTarget could possibly be a BaseFunction, I'd need to check if anywhere I the spec distinguishes between it be null and undefined.
2. Redefining Callable as follows:

public interface Callable {
    public Object call(Context cx, Scope scope, Object thisObj, Object[] args);
}

With the eventual intention that functions can handle the toObject conversion of this and similar, internally.
3. Refactor out a JavaScriptFunction object to be used for almost all functions, alongside an immutable function descriptor, and Executable objects which can represent the interpretable or compiled code. This not only helps us fix our representation of generators but also makes it much easier to change our representation of function metadata and will help enable features like recompilation of hot functions. I would propose that the Executable interface would look something like:

    public abstract Object execute(
            Context cx,
            JavaScriptFunction functionObject,
            Object newTarget,
            Scope scope,
            Object thisObj,
            Object[] args);

Keen eyed readers may notice this looks quite similar to our current direct call signatures in compiled code in that explicitly pass in the function object. The function object cannot be combined with the newTarget as one represents the function being run, and the other represents the original constructor that was called.
4. Convert interpreted functions to be JavaScriptFunctions
5. Convert compiled function to be JavaScriptFunctions
6. Convert all our lambda based functions to also be JavaScriptFunctions

[aardvark179]

There is a prototype branch of the interface changes at #2050. I also have a mostly complete prototype 4 and 5, which I will turn into a draft PR soon.

[aardvark179]

The changes for scopes are proving quite large, mostly because there are so many knock on effects from changing that type in the signatures. Currently the additional changes on top of the other signature stuff is about 1200 lines changed. I think this will take a few attempts to try and find the right set of API changes needed and then apply the large set of mechanical changes caused by that.

[andreabergia]

I'm wondering one thing about point 2 - to implement super() in the constructor of classes, it would be very useful to receive the this object for a constructor function.
The child class should create the new object, and the base constructor should be called on the same object. We can probably leverage the Executable interface, but I just wanna be sure that we design something where we can plug this in easily.

[andreabergia]

newTarget could possibly be a BaseFunction, I'd need to check if anywhere I the spec distinguishes between it be null and undefined.

From MDN:

new.target is guaranteed to be a constructable function value or undefined.

Which is annoying, because (ab)using Java's null to represent javascript's undefined would be very confusing, but on the other hand it would be nice to get a BaseFunction...

[aardvark179]

So I’m making very good progress on the function refactoring side of things. This has substantially simplified class generation and produced some good performance improvements because it has got rid of almost all the methods that switched on method index. Still need to fix that for indirect calls.

One thing that has come out from that is that I think Script is another interface that should change, but that can be done entirely with adding methods with default implementations, so should not break any external use.

Not quite ready to make a draft PR, going through a little internal churn with types which I want to get settled first, and some type casting that’s currently needed is causing a lot of formatting changes right now which makes the diff much larger.

[aardvark179]

@gbrail. I now have some working prototypes:

1. Factoring Scope out of Scriptable - https://github.com/aardvark179/rhino/tree/aardvark179-call-refactor
   This is relatively cleanly separated into introducing the scope interface, changing slot access, changing call, changing construct, and then finally tidying up some things in class compilation. There could still be some refactoring to separate out a concrete ScopeObject etc., but I'm not sure they need to be done right now.
2. Separating code and functions (done on top of the other prototype) - https://github.com/aardvark179/rhino/tree/aardvark179-function-refactor
   This second one definitely needs separating out in more easily reviewable chunks now that I've got it working for interpreted and compiled code and I am relatively happy with the shape of it. Script still needs some work and I think I can do a little more work on class compilation to avoid all the check casts to function objects. I should also probably put together a big ToDo list of things that we now try and implement or improve with this change, because I think it will help unlock a lot.

[aardvark179]

I've adjusted my prototypes to change Scope to JSScope. The reason for doing that is that we already have Scope in the AST nodes, as an annotation in JMH, in our internal code base, and probably more, so the chance of needing fully qualified class names in annoying places was just to high.