I think it would be a bad idea to move forward with GM using an API that breaks compatibility with existing userscripts, and with alternate userscripting extensions.
I can't speak to wOxxOm zOo's discussion of internal implications for an asynchronous API. But I can make some suggestions in terms of how to progress the API balancing the need for optimal performance, and compatibility with a substantial number of existing userscripts. Let's not forget that the GM API has been extended, but remains largely unchanged for over 10 years. That is quite a legacy. Suggestions follow below... On Tuesday, May 16, 2017 at 12:51:48 AM UTC+10, Anthony Lieuallen wrote: > > On Sun, May 14, 2017 at 1:39 AM, <[email protected] <javascript:>> wrote: > >> An alternate related approach is to look at the implementation of TM, and >> advance that as TM did with GM. How did they implement asynchronous >> functions for the webextensions API? Learn from the TM folk in terms of >> how they went about their GM fork. They must already be supporting async >> calls in the API already, given its webextensions-based anyway. >> > > Tampermonkey is not open source, so I've got no plans to try to "take" > from it. Where I've heard other people describe it, it sounds like they've > made compromises to provide compatible calls. Ones I'm not excited about > emulating. > My mistake Anthony. Assumed it was OSS. > > On Sun, May 14, 2017 at 5:15 PM, jscher2000 <[email protected] > <javascript:>> wrote: > >> Given this current pattern: >> >> var sData = GM_getValue("serialized"); >> var oData = JSON.parse(sData); >> // useful things happen here >> > > Good point. If we go all-new async (2.2), I'd expect this would turn into > something like: > > GM.getValue("serialized").then(sData => { > var oData = JSON.parse(sData); > // useful things happen here. > }); > Or using ES2017, something like: let sData = await GM.getValue("serialised") ; let oData = JSON.parse(sData) ; // useful things still happen here. FF 52+ supports async functions <https://kangax.github.io/compat-table/es2016plus/> and the new webextensions API only <https://wiki.mozilla.org/WebExtensions/Roadmap> change isn't due until FF 57. ES2017 is still in draft, but I expect adoption will be rather swift in the coming years, just because it simplifies the syntax so much. So moving forward, GM v4 could implement a new API that uses only ES2017 async functions, while GM v3 remains using the old API and compatible only with older FF. To provide backward compatibility with existing userscripts, and keep GM v4 compatible with other userscripting engines, perhaps GM v4 could include a transpiler that can convert existing scripts into ES2017 type syntax that is compatible with the GM v4 API. This transpilation could occur on script install. The above approach means that GM can perform optimally, and is backwards compatible with existing scripts and those of other userscripting engines. Thoughts? Damo. -- You received this message because you are subscribed to the Google Groups "greasemonkey-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/greasemonkey-users. For more options, visit https://groups.google.com/d/optout.
