Why is this a data property rather than accessor property?

[annevk]

Precedent for getting the global this value are all getters.

[ljharb]

node's global isn't a getter, it's a data property - i didn't think to check what window, self, etc were before writing this spec.

However, generally getters are only usually used in the language on a prototype (to share functionality across instances) - what would be the advantage of a getter here?

[SMotaal]

One clarification, is this property mutable? I confirmed it was in a few places at least.

If it is mutable, it might be worthwhile considering if mutating it needs to have any side effects, is there such concerns for web contexts — relating likely to Window/WindowProxy?

With a setter, you keep track of the assigned value — in such cases, would tracking this value beyond the confines of the global object be an additional complexity and would that be in scope here?

[ljharb]

Yes, like most things in the language, it is mutable. Web contexts who use WindowProxy can decide what side effects it needs to have, but the spec mandates none.

That’s also a good point with the setter - there’d be no good way to track it. However, in that case it would only be an accessor, with no setter.

[annevk]

FWIW, I'm happy with closing this. I'd prefer consistency, but ECMAScript probably uses data properties for a bunch of things that can be used to argue that consistency is here, just with different things than I'd like.

[ljharb]

Given NaN, Infinity, undefined, the builtin namespaces, console, and the data properties on Math, I think that without a compelling reason to use an accessor, the ES convention would be to make it a data property.

Closing for now. Thanks for the issue!

[hax]

@ljharb

like most things in the language, it is mutable.

NaN Infinity undefined are non-writable (and window in Chrome is non-writable, in other browsers it's a getter without setter), why globalThis is writable (mutable)?

[ljharb]

@hax in general things have to have a very strong reason to be nonwritable; part of the requirements in the explainer is that globalThis has to be virtualizable, which requires that it be writable.

[hax]

@ljharb As I pointed out, window is already non-writable in all browsers. Even non-writable globalThis is "virtualizable" (PS. I don't find the definition of it in this repo), you still need to find solution to make window "virtualizable". If there was a solution, it could also apply to non-writable globalThis.

[ljharb]

I don’t see a compelling reason to make it nonwritable; the overwhelming convention in JS is that all builtins are mutable, and there are very few exceptions - which are usually for legacy reasons. Either way this is off topic for this issue; please file a new one if you wish to discuss it further.