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.
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 chimento gmail com> wrote:On Sat, Apr 15, 2017 at 1:41 AM Andrea Giammarchi <andrea giammarchi 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.