a set of names for consideration #32
Comments
Could you please remove the strike-through formatting? It’s really hard to read it like this. Also, I don’t believe |
change to
Then you can take out the strike-throughs. Scott |
@ianstormtaylor it's a bit late for suggestions, as we've already selected the name As discussed in #31, it's not introducing a new concept - it's what the concept is already called in the spec, and it accurately reflects what it is. I appreciate the feedback, and I'll give my thoughts on your suggestions below regardless:
|
@ljharb what does "beginning to ship in browsers" mean? Does that mean it's only in nightly versions of them? Or even that is still in a bug tracker to be implemented?
Re: "not a new concept", that's true. But there are lots of concepts that are in the many specs that don't translate well to developer's mental models or good developer experiences. I think @rauschma made a good argument for this. And if there's any way for us to improve the naming still I think we should take it. Re: Re: But what did you think of my top-three list above? |
I don't agree that "common" and "shared" are used interchangeably with "global" in JS - "global" has a very specific meaning, as it refers to global variables, and colloquially, the global object - whereas "shared" and "common" are terms I see more often in terms of shared helpers in a library, or common CSS styles in a web application. I totally agree that "global" offers similar issues about "well, it's not really global across realms", but the already-adopted legacy and community usage of that term imo trumps that confusion. |
Yeah, but no one has an issue with the "global" part of it. It's the "this" part of it that is the issue. The argument is... Right now there may be a concept of "the global this reference" in the spec. And that's fine for spec people to call it that. But everywhere else in JavaScript we've been trying to get away from using "this", because it is rife with confusion. So much so that as new JavaScript features have been introduced, they've actively worked to eliminate Not only that, but it will also not match what people want to use it for! The reality is that end users are going to use it as a global namespace for putting shared (or common) references to things that need to be global. That is the 99% use case. And that's why I've argued above that since
Otherwise, we're just spec'ing something that is guaranteed to cause more confusion. Why add yet another wart to the spec when there are alternative choices that don't have the same issue? |
I don’t agree that
|
I don't actually think that most end users will use this feature - and I certainly hope that the years-old best practice of never creating global variables doesn't change as a result of this proposal. If you want a place for shared things, make a module for it :-) For what it's worth, I did check the web compat of |
Do you remember why |
@ianstormtaylor because too many websites were using that name already, likely in a way that would break if it was an existing identifier. I assume that it's aesthetics - double underscores are ugly, and only exist on legacy Typically I'd point you at the meeting notes, but it doesn't seem like detailed notes were taken about name bikeshedding. |
Was |
@suchipi it was, but it was removed because the pascal case is reserved for constructors, namespaces, etc. But honestly, seeing as the "global" is mostly a namespace I don't really see why it wouldn't be a good fit TBH. I'll add it, good point. |
Yes, it was in my original list of possibilities, but the general reaction I got was that it's not a constructor and not quite the same as a namespace like Math, JSON, Reflect, etc. At some point, I had to create a minimal list of 3-5 possibilities in order to gather web compat data, and I had to make a judgement call to prune the longer list down to that. |
Even with common pascal case conventions aside, I think it's the most palatable remaining choice |
@ljharb what were the 3–5 choices that you gathered data about? and what was that data? |
@ljharb we all appreciate the work you put into this but I think this is the community telling you you made the wrong judgement call- it's not too late to go back yet. |
@suchipi So you find |
@ianstormtaylor the data is merely, how many sites are using the global identifier - it was All of them had large enough usage that the web compatibility risk was nonzero, but globalThis had nearly none. |
Let's ask for the opinions of others. I'm not sure exactly who "others" should comprise, but probably at least @rauschma, @getify, and @ianstormtaylor, who have shown interest. |
Gathering feedback is great, and I welcome it! However, given conflicting opinions, are you suggesting that sensible language design should be conducted via polling? |
No; don't put words into my mouth. I don't think that's a catch-all solution, and applied liberally it will only lead to bikeshedding hell. However, I am interested in the insights of those three individuals, because they might provide more information that could help us weigh one name over another. I think that given our situation, there's no clear reason |
The clear reason to use it is that it's the global |
While that is clear to you, someone who is impressively familiar with the spec, I highly doubt it will be clear to the average JavaScript user- especially as more usage moves to modules instead of scripts in the future. |
What I would have suggested is...
But to me, it sounds like what happened was...
It doesn't surprise me that this didn't result in a solution that everyone was pleased with, because lots of people were never solicited, and even many of the solutions that were posited weren't really considered. It's not really how good design is achieved, you don't artificially constrain the inputs from the outset. Finally, the most frustrating thing about all of this, is that there is seemingly zero documentation for any of these decisions. Which works well because then it becomes even easier to throw out suggestions as "tried it, didn't work". Which is extremely frustrating. |
sounds like it's too late to make a change, but was |
Moving my bikeshedding suggestions here: globalContext Here's something out of the box: globals |
@ianstormtaylor i discussed options in #20, as well as with committee members, but yes, ultimately i made a choice (after making every suggested option available to committee members) - that’s how proposal champions are supposed to operate. Part of the issue is that it’s hard to gather this web compat data, so we can’t do it for the whole list. Any choice made would have involved preemptively discarding some alternatives based on our collective intuition - that’s what happened here. I’ll take responsibility for insufficiently documenting the naming choices, and I’ll update the readme tomorrow to hopefully clarify the history there a bit. The reality, though, is that no matter how many people are consulted, every decision made will fail to please everybody. It’s certainly unfortunate that people aren’t happy with this choice. |
@getify “Context” isn’t an option that was considered, but to me it means much closer to “scope”, which for the reasons above would be both an incorrect and imo much more confusing name. |
|
I'm starting to think And on that: The name was ruled out because it implys "give me the global this value" What..? So... We've ruled out one option because it implys global this, but we've decided on I'm really starting to think this is just about pushing something through without regard for quality of result. |
@KoryNunn context-based names are mentioned here: https://github.com/tc39/proposal-global/blob/master/NAMING.md#names-ruled-out-by-this-restriction-6 |
I don't consider scope and context to be the same thing. The scope of a function holds its identifiers, the context of a function is an object that is in the Im not sure how it would cause confusion since it seems like what is being described is literally the default context. I'd like to know if my definitions are in line with how other people view these words. |
With that definition, how is globalContext any less confusing than globalThis? It seems like it’d just be picking a more confusing synonym for the same concept (assuming your definition) |
I think because •this• is naturally something you are pointing to and sometimes it is not there where you think it should be. Context is more abstract, kind a 'hidden' already. Wrapped around the whole shazam. I think @KoryNunn has the point. |
Context is a generic term. Context also doesnt add confusion to an already challenging thing to teach. I used to teach people by implementing the 'magic' and showing them how stuff works. Lately I have to put astrixes on everything because many recent spec additions have an ' oh except for X' ' "Oh so what's globalThis?" 'its the global context and doesn't have to be in a function' "...oh" |
from a usability standpoint,
|
From mobile developer standpoint, |
@KoryNunn The word I’d use there instead of context is “receiver”; its context imo is the lexical scope it was defined in - since we have different meanings for it, can you consider that perhaps “context” is confusingly ambiguous? |
I wish I had the power to cancel this proposal. @ljharb it's never late to be reasonable, you can change this. |
@aminpaks this isn't a great way to continue the conversation, and it is very disrespectful to the proposal author. Proposals are a lot of work, and when a proposal in it's third stage, it is something that the committee has agreed upon as being needed in the language in some form. Even if the champion has abandoned it, it is likely to be picked up again. There are a lot of reasons that have little to do with the naming, specifically interoperability between node and the web, that made this proposal necessary. To move this conversation in a productive direction, I have two suggestions: Rather than insisting on a name that has already been ruled out (incidentally, in many cases not by @ljharb, but by other committee members): One might argue for something that would be possible that is beyond what we have already discussed and is already in the document detailing constraints. Incidentally, I would like to point out the following:
Is there another proposal that works for you folks that works within the constraints? This can be treated as a creative exercise and a way forward -- so far it looks like we are looking for something that is On the other hand, one might argue against a constraint in a detailed manner. If you wish to argue against a constraint, but you find that the document is not detailed enough to do so, you can ask and we will give you more information. It looks like the section on Hopefully this can help us move forward. |
@codehag Why is it disrespectful? Doesn't matter how much effort you put towards the wrong direction, it doesn't justify it! |
@aminpaks, what don't you like about it? i'm ok with its current-form and use it in production with following polyfill. it simplifies writing unified, globally-aware integration-code that you can copy-paste and run/debug in browser/nodejs/dev-console. /*jslint browser*/
/*global globalThis*/
(function (globalThis) {
"use strict";
var local;
// init globalThis polyfill
(function () {
try {
globalThis = Function("return this")(); // jslint ignore:line
} catch (ignore) {}
}());
globalThis.globalThis = globalThis;
// init local object
local = {};
local.local = local;
globalThis.globalLocal = local;
// init isBrowser env-test
local.isBrowser = (
typeof window === "object"
&& window === globalThis
&& typeof window.XMLHttpRequest === "function"
&& window.document
&& typeof window.document.querySelectorAll === "function"
);
}(this));
// run globally-aware browser integration-code
(function (local) {
"use strict";
if (!local.isBrowser) {
return;
}
...
}(globalThis.globalLocal));
// run globally-aware nodejs integration-code
(function (local) {
"use strict";
if (local.isBrowser) {
return;
}
...
}(globalThis.globalLocal)); |
@aminpaks Your comment is disrespectful, because it implies that that the champion is not being reasonable, and this has no place in this discussion. Please keep your comments on topic, and keep references to the attributes of specific individuals that you may disagree with to a minimum, as this makes it easy for the thread to get heated and derailed. To repeat myself: regardless of if a champion abandons the proposal, it is already at stage three, which means that a committee consisting of representatives from various companies and frameworks has agreed that a solution to the problem must be made as the problem is significant enough. This includes representatives from the JS foundation, facebook, google, microsoft, mozilla, etc. It does not mean that the solution in its current form is the right one. Proposals in stage 3 are subject to change. If you find our staging process confusing, please refer to our staging document |
@aminpaks -- I should say, Sorry I also lost my temper a bit and had to edit my comment, I also find this thread frustrating. I am hoping we can turn this around. |
I'm very late for this discussion, just give some thoughts. First, personally I'm ok with But I have a very big concern about the process of choosing the name. IMHO, the current process of TC39 have big problem in all similar controversial issues. Not only the name issue of this proposal, but also One of the big problem of current process is, the voices of community can be dismissed too easily, on the other hand, the opinions of a single TC39 delegate can just stop the thing and make all community efforts useless. This is why many community members feel very frustrating. Use this issue as an example, it's ok to rule out some names as the reasons listed in NAMING.md, but why it's not ok to rule out This is very very harmful to the relationship of the committee and the community. TC39 use the process of "consensus in the room". It's ok for most issues, but hard to work for the controversial issues I mentioned before. When an issue is controversial, it means there are essential conflict (of use cases, or mental model, or positions, etc.) somewhere. Normally we hope TC39 make tradeoff based on reasonable technical reasons. Unfortunately, because it's an essential conflict, it will be impossible to convince all, so the champions will choose first satisfy the guys in the room. I don't think it's wrong, the guys are in the room because they have big concern about that topic. But the consequence is if people which have very different opinions are happened not in the room, or if there is no TC39 delegates share same opinions as a large part of community (like dislike of I hope the members of TC39 could recognize such process failures, and try to establish some new process to deal with such cases. And because they are process failures, we should not use "already stage 3" as the excuse to refuse the changing (like the suggestions of roll back to stage 1/2). To me, the most frustrating thing is not specific issue, but the meta issue of TC39 can not fix the process issue. In Oct 11, one of a important TC39 delegate who is the champion of many proposals wrote a letter to me privately:
I hope the author of this letter can forgive me to make it public. But I have to say I'm really frustrating to receive such a mail, if a guy in TC39 like you can not fix it, how can I do anything ?? This is why I never reply this mail. I'm even more frustrating that after I showed this mail to some other TC39 delegates, some still don't agree there is a process failure. Sigh... God bless JavaScript, and Happy New Year (let's temporarily forget all such things and enjoy the holidays :-) |
@hax thanks for your thoughts, I will try to respond as best I can. These are very serious issues that we have been trying to work on. The TC39 is in a transition period, we are trying to understand how to do what we do better, in a more transparent way. This will make us make better decisions as well as avoid such situations. Unfortunately this process of change is not without pitfalls and we are bound to make mistakes, so I hope people will be patient with us. Specifically in relation to this proposal, the NAMING.md file was part of a strategy to make it possible for the community to clearly see the constraints, in order to make it easier for members of the community to engage. @leobalter will be bringing up |
I still say, RFCs are a solution that can help improve the process. If feedback is needed for more than one stage, then there can be multiple RFCs. In fact, instead of saying, "the community can chime in at any time they want", which makes gathering the feedback piecemeal at best, the TC39 can specifically ask for feedback - at - the - right - time, allowing for the feedback to be better funneled and collected. The TC39 can be open for other feedback at any time despite the RFC steps too.
I like the humility here. We are all only human. Scott |
@ljharb, @codehag I need to apologize for what I said a couple of comments on top. I lost my temper due to frustration (no excuses though) and I shouldn’t have. I think a couple of comments above things that frustrate me have been mentioned by @hax. Still I believe we should put way more efforts towards fixing the process. (I don't know how to fix it though.) Thanks for your hard work. |
My couple of cents. On the immediate problem at handI second @nuragic's comment, in #32 (comment). For me, either On versioning JavaScriptI think @anurbol's proposal for JavaScript versioning is great — see #32 (comment) and #32 (comment). Unfortunately, imo, this is one of those aspects of the JavaScript language that TC39 isn't brave enough to tackle. Or, maybe, it is yet to recover from the effort of defining the strict mode... Instead, TC39 rushes into and becomes overwhelmed and overloaded by a multitude of new, nice-to-have, could-definitely-wait-for language features. Imo, in the long run, this modus operandi effectively jeopardizes said features, by drastically reducing their solution space due to the (real) constraint of backward compatibility. Versioning would preserve the full solution space and would ultimately result in better solutions. One of the arguments against versioning, mentioned by @ljharb, in #32 (comment), leaves me astonished:
If we weigh pros and cons, for the language, the community, the web — the world, after all — how can browser convenience weigh more? While I see the danger for the creation of many versions, I can also see how this feature could be used sanely, by adequately grouping incompatible features, to serve advancements in an opt-in fashion to the web. There could be, for example, one version per year, aligned with the ECMAScript's yearly release (the old 5, 6, 7, ... numbering could be used). This would also be a great feature for linters and developers, allowing the code to state the ES language level for which it was written for. Feature testing is great (more like a necessary evil?). Version assurance is better, imo, and the only real enabler of backwards incompatible changes (such as syntax changes). Feature testing would still be necessary for the detection of other web platform features and APIs. Possibly, language versions could also reach an end-of-life. Would a life-span of 15 years be reasonable? How many pages that use JS and are not modified for the last 10 years still run without errors today (despite our best efforts)? And for 5, and 15 years? Is there a more reasonable, realistic, version of (pun intended) "the web does not break, ever"? In principle, only a small number of features, across multiple yearly versions, and most of small complexity, would need to be explicitly handled by browsers. Yet, I'm sure there's a tonne of problems in here, but few, if any, should be unsolvable by your great minds :-) Importance of namingI second @getify (#32 (comment)) (and others) on the importance of naming. I would dare to define naming as:
In the absence of a proper name, there's no real understanding of the problem at hand. Deferring the choice of a name is, most of the times, a direct consequence of the lack of understanding of a problem. Of course, ultimately, several names can match a well understood meaning (semantics), allowing for a final choice to be made later in the process. Another aspect of the naming problem is extrinsic and deals with how it is perceived by several target audiences. (Descriptive) Names summarize concepts in the best possible way and they're one of the key (pun intended) things that we humans use to efficiently memorize, predict and understand information. Names last, for better or worse. Finding names parallels with finding concepts as part of the design process. Oh, yes, it is a hard problem to solve. Not one to be underestimated, either in impact, effort or importance. On the TC39 ProcessI also think that lessons can be taken from this proposal's development (and, possibly, from others, as mentioned by @hax, in #32 (comment)) and well (better?) defined points for community involvement could be identified and formalized into the TC39 process. This would help both TC39 and community people to concentrate their efforts and attention at specific times. It would greatly help the community not to miss the wagon passing by. See @smolinari's comments on the topic: #32 (comment), #32 (comment), #32 (comment) and #32 (comment). Also, see @leobalter, in #32 (comment). On the perceived power of JavaScript engine makersI'm a bit chocked by the reality so clearly described by @codehag, in #32 (comment):
I think I understood the described dynamics of the JavaScript engine market. I conclude that engine makers have an undesirable amount of power on the web standards equation; or, the market they live in forces them to act very conservatively, as a way to protect their "business". While I do believe that no engine maker wishes to harm the web, surely, many times, it is not in their best interests to implement a given feature. Legislation is commonly used to regulate markets... Could/Should engine makers having a fixed seat at TC39 have (more?) obligations as well?
Surely, some rules could be thought of to bring some balance to this apparently uneven state of affairs. |
@dcleao Thanks for your thoughts! I appreciate your feedback. I wanted to reply to a few points you made on versioning and engines:
if browsers refuse to ship something, then nobody gets to use it. If browsers were unwilling to ship versions (note, I'm not claiming they absolutely are, but I suspect they would be), then versions would either never land in the spec - or worse, would land, but never be implemented, making them de-facto non-standard. There's not really a feasible way to force private companies to ship changes in their privately owned and managed software products, nor would it universally be considered a good thing to have a world with that kind of coercion. There's the secondary concern that many browser versions do not implement precisely 100% of a given edition, and no further - for example, no engine fully complied with ES5 until a year or three ago, despite implementing a great many newer features. Experience and industry advice tells me that feature testing is reliable; whereas version testing (or user agent sniffing) are what's inherently unreliable, because (just like browser user agent strings) versions are often deceptive. There's plenty of times, for example, that a browser (that all of us, I'm sure) shipped a feature, claimed it was "done", and then it had bugs - at that point, you'd either have to maintain a complex table of version numbers mapped to feature tables, or, you could directly feature-test and always find out whether it works as you expect or not. |
@dcleao Your comment (all of it) is like a breath of fresh air, thank you.
browsers are people behind them and those people are developers as well, with a sense of beauty (regarding the language), I hope. P.S. Not to make this discussion bloating up further, just added 2 cents. |
I don’t find versions “beautiful”, and i suspect I’m not alone in that given the committee’s and browsers’ historically consistent and strong stance to not ever version the language. |
'global' is the ideal name. Since it's being used by Node.js already, I prefer 'globalThis'. 'Global' looks like a class, because the uppercase letter in the beginning is conventioned for classes. |
The blacklash this proposal is getting is well overdue thanks to this post.
Pretty much every other suggestion is better than |
@srsgores it’s not catering to node at all; code on the web breaks with “global”. Every browser has shipped globalThis, and has also been unwilling to try any other name. No change can be made. I’m going to lock this issue; please give https://github.com/tc39/proposal-global/blob/master/NAMING.md a thorough read before filing future questions about naming rationales. |
Hey all.
First, I just want to say thank you to @ljharb for writing up and championing this proposal to get it this far. I think it this entire proposal is a great idea for something to standardize.
I only open this, because I've read through all of the naming discussions and the ad-hoc suggestion flinging that happened over many old issues, and thought that it wasn't really a good approach for the mob to find the best name. (Mobs are good for finding potential names, but not really for presenting good arguments for or against.)
So, I'd like to present a small selection of names, in the hope of preserving the original intent that @ljharb had for this proposal, while also taking into account @rauschma's well-intentioned worry about "this" causing confusion in #31. Please, hear me out! Thank you all.
So...
Non-recommendations
Before talking about naming choices, I just wanted to try and summarize the main choices that had been made previously but are now removed from consideration, so everyone's on the same page, and so we don't end up with mob rule again. (I did my best to try collect the actual reasoning why things were removed from consideration, but sometimes it really wasn't clear, which might have been part of the issue with the process.)
— Removed from consideration, unfortunately, because it breaks existing websites (like flickr.com) that rely onglobal
global
not being defined in browser contexts. This was obviously the top choice.— Removed from consideration (or never was considered) because it breaks existing code that relies onwindow
window
implying a browser. Also it doesn't make sense for non-window-based environments to define a global variable called "window".— Removed from consideration becausethis
this
is not available in modules or in strict mode. Also, people have lots of trouble understanding JavaScript's "this" concept, and adding more confusion by using it for more things is the opposite direction people are trying to go. More and more features are being added that remove the need to think aboutthis
, and I think that's a good thing. I'd argue thatthis
ever referring to the global namespace was a strange quirk in everyone's mental model.— Removed from consideration because it is already exposed as a global in browser environments where it has similar but different meanings, so it's not an option.top
— Removed from consideration because they didn't want to tie it to one of the existing or future namespaces, because it should be a global variable itself. And in the case ofSystem.global
,Object.global
, etc.Object
because it would mean that any object could access its global variable context which is unintended.— Removed from consideration because it goes against how browser runtimes actually work, because they differentiate between the "global object" and the "global this value", and the committee does not want to incorrectly name it after another concept that is not what it really is.globalObject
— Removed from consideration because they all are named after pre-existing concepts in JavaScript (or in specific platforms like node) that this globals proposal has nothing to do with, and would cause confusing overlap for users.globalScope
,globalMap
,globalExports
,globalEnv
, etc.— Removed from consideration because they are awkwardly named in a way that userland variables never really would be. Yo would never name a variableglobalVars
,globalRef
,globalValue
, etc.thingValue
,thingRef
orthingVars
, you would just call itthing
(orthings
) by itself without the suffix. This is an aesthetic point, but ideally we'd be able to avoid these awkwardnesses if possible.— Removed from consideration because they are also awkwardly named in a way that uses two words that mean the same thing just to avoid a naming conflict. It would be like naming a variableglobalRoot
,topGlobal
,rootGlobal
, etc.homeHouse
orcarVehicle
. If we absolutely had to resort to names like this they surely wouldn't cause compatibility issues, but it seems like something we should try to avoid if at all possible.— Removed from consideration because nowhere else (that I know of) does JavaScript include an article in the name of a variable, so it would be very non-standard feeling. I'm sure we can find a less strange way of expressing it. If we really had to resort to this we could reconsider it down the road.theGlobal
— Removed from consideration because the name "store" is already often used in JavaScript (and elsewhere) for implying some sort of persistent storage, and the global namespace is not persistent in any way. Additionally, on the web there are already many types of storage (eg. LocalStorage, SessionStorage, etc.) so this could cause unnecessary confusion for people.store
,globalStore
, etc.— Removed from consideration for now, for a few reasons. The primary one is that although "context" is a less-fraught way to refer to JavaScript's "this" concept, it would still be naming it after a mental model that we are trying to avoid, since it assumes people think in terms of "give me the globalglobalContext
this
value", which is not common. We'd rather work towards the 99% mental model case of "give me the global namespace". If it was determined that we absolutely had to fallback to a longer, camelcased name like this, this seems like the best choice, because it doesn't have the overt negatives of some of the otherglobal*
suggestions. However, "context" is a concept that so up to now has been useful to have in userland, as an empty canvas that can be used by libraries for their own needs—eg. its use in Koa and React. So introducing a new term with it causes overlap, which may or may not cause confusion.— I'm marking this as "removed from consideration" for the purpose of presenting what I hope are better alternatives. But obviously this is the current running name. But, like @rauschma argued, it adds confusion by re-introducing "this" into a new place in JavaScript for people to learn.globalThis
So where does that leave us?
Ideal Candidates
I think everyone can agree that
global
would be the ideal name, if only it had been compatible. So I think it makes sense to look to try to preserve its semantics as much as possible.As the top set of choices...
Global
— There was discussion of this, but it was thrown out because the pascal-cased names are supposed to be reserved for constructors and for namespaces. But when you think about the 99% use case for people, the "global reference" is always for namespacing reasons, and it is often referred to as the "global namespace". So to me it seems like an extremely relevant naming choice. This would preserve the greatest level of intent (since it's exactly the same word, just different capitalization) as the original name proposal. I think it may have been discarded too quickly.GLOBAL
— This variable surely would be constant, since it refers to the top-level global this/object for the environment, so why not name it as constants are often named? In fact,GLOBAL
is already exposed in node as an alias forglobal
, so there is prior art showing that this is a reasonable naming choice. Using it would also preserve the maximum level of intent.__global__
— Although this is "ugly", it is notable that there is convention for it, since__proto__
is already in JavaScript, and people often use the same double underscore convention in their libraries for private values. And it's worth nothing that there is prior-art of other languages like Python using the double underscore for built-ins that need to not conflict with userland, like__init__
. If anything, it would make people think twice before doing too much with the global namespace which seems like a desirable outcome to me. (The same way that__proto__
does.)globals
— Another idea would be to use the plural form. Environments that have an existingglobal
defined can now treat it as an alias, and other environments get to have an almost-identical-in-intent named variable. The plural form also feels nice when accessing a global property (eg.const { myThing } = globals
), since it's very common for people to name objects/namespaces using plurals.In my opinion, those are the best choices because they preserve the original semantic intent of @ljharb's proposal most directly, while also not resulting in more awkward naming like
globalObject
, or potentially confusing names likeglobalThis
.Fallback Candidates
However, if none of them can be proven to be usable for compatibility reasons, I'd also like to present a few fallback alternatives...
root
— If we don't wantGLOBAL
or__global__
because they aren't a "standard" lowercase-named variable, then I think "root" is the next best choice. This word is also frequently used to refer to the top-level object or namespace in programming. In fact,root
is already exposed as aglobal
alias in node so it has prior art that could make it a good candidate. And since browser environment checking is often done viawindow
orself
, it seems less likely to cause compatibility issues, although this would need to be vetted.self
— This would be an apt name to choose because it is already implemented in browers and in Web Workers to refer to the global object, so it has prior art that people are used to. The issue with this proposal, and why it isn't higher in the list is that it has the potential to break node compatibility in cases where people are currently usingself
to check for a browser environment and do non-node things. The counter argument to this worry is that it's okay for node to release a breaking change using semver. There's another worry that "self" is often a term used in other languages (eg. Python, Ruby, etc.) that refers to an "instance" of an object, which is completely counter to the idea of referring to a global singleton, and this could cause unnecessary confusion. But these worries are something the committee and node would need to weigh. It would obviously be nice to be able to re-use and existing name instead of having to invent a new one.common
— It preserves the semantic intent of a shared namespace. It is also a very uncommon variable name, so it won't cause confusion with userland code. And it has prior art in thatCOMMON
was used for the same purpose of accessing global variables in Fortran II (and probably other languages that followed as a result).shared
— Similar tocommon
, but with less prior art. Usingshared
would also preserve the semantic intent of "global" referring to a shared namespace.globe
— It doesn't necessarily preserve the semantics of the original "global" name, but it does get close to it in spelling to preserve that aspect of it and keep it closer to what people recognize. It's also a very uncommon variable name so there would be no real worries about conflict (either in compatibility or in general usage).I don't pretend to be able to make the final decision, since it requires a lot more JavaScript ecosystem knowledge than I have. But I'm hoping it can be useful to present the sets of names all at once, taking into account compatibility as well as developer experience reasons for/against each.
Thanks for listening! And thanks again @ljharb for this proposal.
The text was updated successfully, but these errors were encountered: