Static functions don't have the same risk as prototype functions; `Math.mod` would make sense to add.
One suggestion, though, would be to try to add the API method first, and look at usage for awhile before trying to add the syntax. On Thu, Aug 15, 2019 at 10:12 AM Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > 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 <t...@thenewobjective.com> > 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
