Open zloirock opened 2 years ago
Thanks for raising this issue.
From what I recall, SugarJS stopped conditionally monkey-patching Function.prototype around 2016 (see also Bugzilla 1750812). So this partially depends on whether there are any codebases still in use today that use that old version of SugarJS. (As long as the monkey-patching is not conditional, then it’s okay, but the old version of SugarJS did conditionally monkey-patch, which is why Array.prototype.groupBy broke code that used the old version. 😔)
We will have to determine whether that old version of SugarJS also monkey-patched in Function.prototype.once.
We will also have to closely analyze Sugar.js’s Function.prototype.once’s behavior and determine which of the options in #2 it matches. It seems like it does cache results, but there are other subtleties that we will have to confirm…
And, yes, we could always use another method name; see #1.
I will be presenting this tomorrow, and I have added this unfortunate issue to my slides. I will also fix the explainer’s section when I have time.
I assume static Function.once
do not have webcompt issue?
Some other implementations in the wild. I don't think any of these will cause problems with webcompat.
bit.js
: https://github.com/krasimir/bit.js/blob/master/src/03.once.jsaroma
: https://github.com/leafo/aroma/blob/511d6892e239e45163b2a7743fa8da290e726b38/nacl/js/aroma.coffee#L21-L27@v4fire/functools
: https://github.com/V4Fire/Core/tree/master/src/core/functools (which also looks to add Function.once
: https://github.com/V4Fire/Core/blob/2c7995d0bd096fc43a6a554f59fb4980a85142fb/lib/core/prelude/function/memoize/index.js#L33)ignotifier
chrome extension: https://github.com/inbasic/ignotifier/blob/d4a87d7618ae5b12937d930d5e4f2b89ddc7e3b1/v1/src/lib/wrapper/firefox/app.js#L37-L46kranium
: https://github.com/krawaller/kranium/blob/70c43b840cba12e14503eefe2cdc69b8bd7b6201/lib/kranium-src/utils.js#L403-L408fanta
: https://github.com/yuanyan/fanta/blob/19c404e5147afb7f5062f1e342f933ba70171020/src/fanta.js#L310-L329ofio
: https://github.com/jifeon/ofio/blob/3e8da2f20a6461b80127fdae40001eb71f61427b/ofio.cache.js#L10-L21PixieEngine/Cornerstone
: https://github.com/PixieEngine/Cornerstone/blob/4fd1e28e71db89385876efe46ca634a90d51672e/game.js#L1208-L1218@hax SugarJS - only in case that no one used it as a shortcut for Function.prototype.once
.
A simple search on GitHub shows many cases usage of static Function.once
like this.
What matters is if the monkey patching of Function (or Function.prototype) is conditional. Unconditional monkey patching won’t be affected by extending the built-in. At least V4Core’s monkey patching does not seem to conditional, so that’s good.
One possible solution of webcomp is using meta method syntax, function.once
or do.once
( do.once
may be not good for this proposal, but do.pipe
seems ok for Function.pipe
proposal.)
that would be pretty annoying to be forced to wrap it in a function in order to pass it elsewhere; it’d also make it impossible to polyfill.
Yeah, so I think Function.xxx
should be the first choice for helpers proposals.
But if we are considering some syntax proposal, for example, extensions or call-this proposal, we could consider something like value->do.pipe(f)
(or value->let(f)
if use Kotlin-style name).
But if we are considering some syntax proposal, for example, extensions or call-this proposal, we could consider something like
value->do.pipe(f)
(orvalue->let(f)
if use Kotlin-style name).
Although I applaud the creativity; this proposal is for a tiny convenience function. I think it doesn’t deserve the huge complexity burden of new syntax. 🙂
There are always alternative names if the pre-2016-SugarJS problem ends up being insurmountable, even if they are worse than once
. Like oneTime
and onlyOnce
and singleTime
and limitOne
.
As I already wrote,
Function.prototype.once
is available in SugarJS (and IIRC in some other libraries). At the current meeting, it was decided to renameArray.prototype.groupBy
because of a similar conflict with SugarJS. Because of this, I see 2 options for avoid this possible conflict: