> Do you know if that's because they optimized it, or they just gave up showing the message?
The thing is that there are no ways to extend natives differently. Imagine you want a Constructor to be an Array, `Object.setPrototypeOf(Constructor, Array)` is the only way to go because you cannot `Object.create` a constructor. This is just an example of how pointless is that message, specially because it's Babel causing it and there's no way Babel should avoid using __proto__ where appropriate. TL;DR the __proto__ bails out optimizations around inferred types so that both the object and the code dealing with such object cannot be heavily optimized. At the same time ECMAScript 3rd Edition was already fast enough with functions, classes, and stuff that has never seen the light of JIT compilers. As summary, that was just an overly-agressive message that someone at Mozilla decided was good to show to developers, the only people that would notice, mostly the one incapable of fixing it 'cause coming from transpiled code that inevitably needs it. The race to close-to-mteal performance for a scripting language can take various unimaginable directions, showing warnings around ECMAScript specifications shouldn't be one of these ^_^ Apologies for the rant and thanks for your answer. Best Regards On Sat, Apr 15, 2017 at 7:27 AM, <philip.chime...@gmail.com> wrote: > On Fri, Apr 14, 2017 at 5:13 AM Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> Actually, after years of developers complaining about the >> overly-aggressive and useless message only Firefox was showing, it looks >> like modern versions don't. >> > > Do you know if that's because they optimized it, or they just gave up > showing the message? > > At this point I believe this is a GJS only issue because it's based on old >> version of moz.js >> >> Is there any roadmap available to understand when I can drop >> transpilation all together and use ES2015 instead on GJS? >> > > The roadmap is "as fast as I can" :-) I think it's safe to say that mozjs > 52 will be landed in GNOME 3.26. > > On Fri, Apr 14, 2017 at 12:43 PM, Andrea Giammarchi < >> andrea.giammar...@gmail.com> wrote: >> >>> > they really really don't want you mutating the prototype of an >>> object. It must really be that slow. >>> >>> It's part of standard specifications and it's cheaper than any other >>> workaround that would avoid using `Object.setPrototypeOf`, including a >>> Proxy. >>> >>> They really should mind their business, or complain with TC39 instead, >>> IMO. >>> >>> As summary, should I blame Mozilla and file a bug there? >>> >>> Thanks >>> >>> On Fri, Apr 14, 2017 at 4:32 AM, <philip.chime...@gmail.com> wrote: >>> >>>> On Thu, Apr 13, 2017, 11:23 Andrea Giammarchi < >>>> andrea.giammar...@gmail.com> wrote: >>>> >>>>> Apparently, the latest GJS warns about "stuff" even if executed >>>>> through GJS_DISABLE_EXTRA_WARNINGS=1 flag. >>>>> >>>>> Gjs-Message: JS WARNING: [/app/lib/jsgtk/jsgtk_modules/jsgtk/babel.js >>>>> 26]: mutating the [[Prototype]] of an object will cause your code to run >>>>> very slowly; instead create the object with the correct initial >>>>> [[Prototype]] value using Object.create >>>>> >>>>> >>>>> This message is completely useless/pointless when it comes to >>>>> transpiled code, and to be honest, it's been always useless on Firefox >>>>> consoles too 'cause developers setting or mutating a prototype 99% of the >>>>> time have valid reasons to do so. >>>>> >>>>> Am I missing yet another flag to ask GJS to kindly "shut-up" or any >>>>> attempt to normalize Gir classes as JS will show these kind of warnings? >>>>> >>>>> Thanks for any sort of explanation/hint about this. >>>>> >>>> >>>> Hi Andrea, >>>> >>>> It's true, this warning is not affected by the disable-extra-warnings >>>> setting. I don't have an explanation why the Firefox devs chose to make it >>>> that way, except maybe they really really don't want you mutating the >>>> prototype of an object. It must really be that slow. >>>> >>>> You could try to use an ES6 Proxy to achieve what you want. >>>> >>>> Regards, >>>> Philip C >>>> >>>>> >>> >>
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
