search

tc39 / proposal-get-intrinsic

EcmaScript language proposal for a way to get intrinsics.
https://tc39.github.io/proposal-get-intrinsic/
MIT License
32 stars 4 forks source link

Open question: Have dedicated literals been considered? #9

Closed celmaun closed 3 years ago

celmaun commented 3 years ago

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.

celmaun commented 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)).

celmaun commented 3 years ago

Well, unless of course the transpiler is allowed to replace globalThis.getIntrinsic with a polyfilled version. Then back to square one above lol.

ljharb commented 3 years ago

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.

ljharb commented 3 years ago

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.

celmaun commented 3 years ago

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 😋

ljharb commented 3 years ago

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.