I can "get" it once I have all the information... :-P Last time I saw your Babel code, I thought you had defined your own transformations rather than using the built-in ones, and that's what I assumed was setting the prototype. I agree, if the built-in transformations use it, then there's not much you can do about it.
On Sun, Apr 16, 2017, 11:56 Andrea Giammarchi <andrea.giammar...@gmail.com> wrote: > It looks like you're not getting it ... Babel transpiler causes the issue > and there's nothing "we" can do about it. > > You cannot avoid __proto__ in certain cases, this is an ECMAScript > documented fact. > > I don't have any issue otherwise, current mozjs has issues showing > warnings it should not (indeed it's been resolved) > > ;-) > > On Sat, Apr 15, 2017 at 7:05 PM, <philip.chime...@gmail.com> wrote: > >> On Sat, Apr 15, 2017 at 1:41 AM Andrea Giammarchi < >> andrea.giammar...@gmail.com> wrote: >> >>> > 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. >>> >> >> I wonder if Symbol.hasInstance [1] would help you, which will be >> available when we land mozjs 52? >> >> At least, for Lang.Class and GObject.Class I found I only needed to set >> the prototype in order to get instanceof to work as expected. Everything >> else worked without setting the prototype. >> >> In the meantime you could consider using __private_GjsConstructorProxy >> [2] but be advised that I'm definitely going to remove that as soon as >> there's a real ES6 way to achieve the same thing. >> >> [1] >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/hasInstance >> [2] >> https://git.gnome.org/browse/gjs/tree/gjs/jsapi-constructor-proxy.cpp?h=1.48.1#n35 >> >> >
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
