thisValue vs global

[littledan]

I see that there are two separate getters, global and thisValue. I wonder if this relates to how HTML has a WindowProxy. In HTML, only the "this value" is ever exposed, and the underlying "global" is never exposed. I think there's only one concept that makes sense for actual JS programmers. We could call it either the global or the thisValue (I prefer global), but I'm skeptical that we should have two getters potentially returning different things. I'd suggest simply removing the thisValue getter.

[ljharb]

Or have only one getter called “globalThis”, to make it clear what value it’s returning?

[caridy]

I'm ok with the simplification, considering that the parameterized evaluator will allow you to control access to the this and the globalThis as well via the lookup hooks that we will provide. Effectively, one of the must-have features of the evaluator is the ability to implement a WindowProxy effectively.

In the realm's proposal, the only reason why thisValue is still configurable (via options) and accessible is historical reasons, it has been there from the very beginning when our assumption was the the Realm will allow you to implement WindowProxy via the handlers for the global object, but that's not longer possible, and it is now on the evaluator to resolve this use-case.

I will bring this up in the next SES meeting, and carry on the changes if we get to some agreement there.

[littledan]

Where's the current best reference for parameterized evaluators? I can see https://github.com/tc39/proposal-ses#the-compartment-constructor but I don't see where the hooks are defined.

[erights]

You found the right place. The hooks will be in the options bag of the Compartment constructor. At https://github.com/tc39/proposal-ses/blob/master/refactor-spec-approach.md#random-notes we've been gathering the things in the spec that look like they might be host hooks. We did some old work back before we split realms from ses to pin down what the API should be for hooking these. We have yet to revisit and update that work.

Do you know of any host hooks or host-provided intervention in JS behavior that we didn't capture in that list?

[caridy]

FYI, in issue #210, @Jamesernator listed what seems to be a very comprehensive list.

[devsnek]

Another issue that I've observed is that if only the thisValue is used, you end up with values that are reachable via globalThis.xyz but not just xyz. I think in most cases this is not what people will want.

[caridy]

@devsnek can you elaborate more? I'm confused by your comment. I think @ljharb suggestion is that we only have one getter globalThis, which points to the Realm's Global Object. And if you ever want to control the this during evaluation, you will be able to do so via the parameterized evaluator (or Compartment as we call it now).

[littledan]

globalThis would be what you're doing a property access on when you do xyz. If you set up a Realm which uses a WindowProxy-like pattern, the underlying "global object" would be inaccessible: globalThis would be the same as the thing that property access is done on for something like xyz. I don't think there are any conditions where we want to allow the this value or the globalThis value to be set separately from the thing that's used as the base to read globals like xyz from.

(One of my takeaways here: calling it globalThis didn't make the WindowProxy semantics clear to anyone.)

[caridy]

To clarify, with the current Realm API you can't implement the WindowProxy semantics. My hope is that this is the kind of things that you can do in the evaluator where you can have a hook to mimic access to the global object and this value.

[ljharb]

The purpose wasn’t to make WindowProxy semantics clear to those who didn’t already understand them, for the record, it was because those who do objected to any implication that it was the global object.