Closed celmaun closed 3 years ago
Also, dedicated literals will likely have massive performance advantage over getIntrinsic function calls. Secondly, transpilers will have a hard time polyfilling if getIntrinsic takes dynamic values... (getIntrinsic(someVariable)
).
Well, unless of course the transpiler is allowed to replace globalThis.getIntrinsic
with a polyfilled version. Then back to square one above lol.
This is not an option, precisely because syntax would make it undeniable - no there are many, many use cases that need to be able to hijack it: polyfills, SES, membrane environments, etc.
See https://github.com/ljharb/proposal-get-intrinsic#first-run-code re “cat and mouse” - like all things in JS, you forever have to make sure your code can run first, or you can’t guarantee much of anything.
Ah I see. Nvm then, I thought this was about providing a way to access to guaranteed untouched intrinsics. I don't think there's a strong enough justification to have such a clumsy thing part of the language in that case.
Your package has five different versions right now as per npm, and new versions will keep coming. And so the web bundles will have ever increasing copies of getIntristic... all this to slightly increase the chance of an "intrinsic".. which can be a polyfill..? A polyfill is not an intrinsic. The whole idea seems kinda pointless.
If someone is going berserk deleting delete globalUniverse
or such. I think it's time to make that lunatic an offer they can't refuse. J/k 😋
They won’t be ever increasing - as supported browsers fall off the list, the number of intrinsics that need polyfilling will diminish.
An intrinsic is anything that exists before your code runs - including polyfills.
It will be a cat-and-mouse game trying to get hold of original intrinsics/
getIntrinstic
before someone else tampers them. So in my opinion this makes more sense as a syntax level thing, having%xyz%
literals . i.e.,const SomeIntrinsic = %IntrinsicName%;
. This rules out those shenanigans entirely.As a bonus/headache prevention, any invalid/unsupported
IntrinsicName
is a syntax error at parse time. Babel/transpilers will take care of providing intrinsics to legacy environments of course (as is tradition with all new syntax). Another bonus, transpilers are in the unique position to put in authentic references to those intrinsics.getIntrinsic('%xyz%')
is prone to typos if it fails silently on invalid names. We should strive for the language to be writeable without IDEs, TypeScript etc.. In good ol' text editors.P.S: I have not checked if these dual percent sign literals will be in conflict with some other ES proposal. V8 uses the
%
prefix for internal method names, but that probably/hopefully won't conflict with percent sign on both ends.