Closed annevk closed 5 years ago
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?
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?
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.
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.
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!
@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)?
@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.
@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
.
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.
Precedent for getting the global this value are all getters.