Web compatibility

[zloirock]

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 rename Array.prototype.groupBy because of a similar conflict with SugarJS. Because of this, I see 2 options for avoid this possible conflict:

• Use the same semantic like in the library - and it's already used in this proposal, but that mean that it can't be changed to another option form Subsequent calls: cache, undefined, throw, or both #2 and other semantic-related issues.
• Use another method name.

[js-choi]

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.

[hax]

I assume static Function.once do not have webcompt issue?

[keithamus]

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.js
• aroma: 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-L46
• kranium: https://github.com/krawaller/kranium/blob/70c43b840cba12e14503eefe2cdc69b8bd7b6201/lib/kranium-src/utils.js#L403-L408
• fanta: https://github.com/yuanyan/fanta/blob/19c404e5147afb7f5062f1e342f933ba70171020/src/fanta.js#L310-L329
• ofio: https://github.com/jifeon/ofio/blob/3e8da2f20a6461b80127fdae40001eb71f61427b/ofio.cache.js#L10-L21
• PixieEngine/Cornerstone: https://github.com/PixieEngine/Cornerstone/blob/4fd1e28e71db89385876efe46ca634a90d51672e/game.js#L1208-L1218
• https://github.com/spolu/pipes/blob/0f335e79c5a046d2533cb3d4b5c5a31d92256404/lib/base.js#L84-L99

[zloirock]

@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.

[js-choi]

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.

[hax]

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

[ljharb]

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.

[hax]

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

[js-choi]

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

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.