extending an ES6 class using ES5 syntax?

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun May 15 08:07:47 UTC 2016


Thanks Andy, I think that bug has exact same concerns and valid answers for
Boris too. Here it's also the only valid option to properly extend classes
in ES5 and I can't wait for such "warning" to go away, most developers have
been scared by the same warning by my `document.registerElement` polyfill
but there's no other way, hence my complain. FF should probably stop
wasting time warning about what devs should do or not, if devs are using
standardized practices. Deprecation is OK, scary messages without details
are just ...yak.
Best Regards
On May 15, 2016 12:51 AM, "Andy Earnshaw" <andyearnshaw at gmail.com> wrote:

FWIW the warning is going away.
https://bugzilla.mozilla.org/show_bug.cgi?id=1049041

On Sat, 14 May 2016, 20:25 Boris Zbarsky, <bzbarsky at mit.edu> wrote:

> On 5/14/16 3:11 AM, Andrea Giammarchi wrote:
> >  1. why is that?
>
> Why does mutating the proto after an object has been exposed to script
> end up deoptimizing things?  Because it invalidates assumptions JITs
> otherwise make.  So the options are to make the
> proto-hasn't-been-mutated case slower by not making those assumptions or
> to make the proto-has-been-mutated case slower.  Guess which one is a
> better choice?
>
> > There is a
> >     spec'd method that is not even on Annex B and Firefox deliberately
> >     discourage its usage.
>
> Sure.  Just because something specced doesn't mean it's a good idea to
> actually do it.
>
> This is why in the HTML spec there's all sorts of stuff that's marked as
> "not valid HTML" for authoring purposes even though the spec then goes
> ahead and defines what a browser should do with that stuff if authors do
> it anyway.
>
> > Why I don't see warnings every time I
> >     `[].slice.call(arguments)`?
>
> Because that's not as big a performance hit?
>
> > I understand it might de-optimize but I
> >     wonder if that's really always necessary (maybe it doesn't have to
> >     deopt if it's a well known operation with a predictable result).
>
> I'm not an expert on the type inference setup (which is what ends up
> deoptimizing on proto mutation, iirc), so I can't usefully answer this.
>
> > On the other side, I also wish Firefox woudn't show warnings about
> >     modern and recent specifications. Deprecated stuff is OK,
>
> There can totally be things that are both recently added to the spec
> (for UA implementation purposes, because everyone has to do it for web
> compat) and deprecated for authoring purposes (because they're a bad
> idea).  Dynamic proto mutation is one of those.  ;)
>
> >  2. where were you when the `__proto__` landed on specs? :P
>
> You mean when every browser on the market implemented it, which was the
> relevant bit?  The addition to the spec was just acknowledging ugly
> reality.
>
> Where was I when browsers implemented __proto__?  We're talking 20ish
> years ago, so probably high school or a few years into college.
>
> -Boris
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160515/960e6aef/attachment.html>


More information about the es-discuss mailing list