To me there's no risk, as MooTools, Prototype, and Scriptacolous are both things of the past, and never implemented Math.mod ... so, with that approach, custom transpiling functions are more dangerous, as somebody might have implemented `%%` already for other purposes, and we break Babel outcome adding new syntax anyway ... the smoosh accident, is the equivalent of custom Babel utilities these days.
Look at TypeScript and the private class fields, if you want to compare new syntax instead On Thu, Aug 15, 2019 at 4:50 PM Michael Haufe <[email protected]> wrote: > Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote: > > > > > FWIW another disadvantage is that operators cannot be polyfilled, so > it'll take forever for those not using transpilers to adopt these, while > having a `Math,mod` would work right away > > > > > > With such an approach there is risk of another ‘smooshgate’ [1][2]. There > is nothing stopping those developers from using a function anyway to bridge > the gap if they can’t or won’t use a compiler. This is already the current > state of affairs. > > > > [1] https://developers.google.com/web/updates/2018/03/smooshgate > > [2] > https://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/ > > > > Michael >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
