> Extend builtins, in particular - ie, `super()` allows your subclass to obtain > internal slots it can't otherwise get.
does extending builtins in the javascript-language even make sense, given the dominant industry application of it in a web-context? as i've said before, the primary industry-painpoints with javascript are integration-related, namely serializing/reconstructing JSON data between client <-> server. whatever low-level benefit you gain from extending builtins, typically is not worth the extra high-level integration-cost of serializing/reconstructing these custom data-structures to/from JSON. p.s. - as an aside, new primitives like BigInt should have focused more on ease-of-use with JSON-serialization. BigInt’s primary use-case in industry as i see it, is as a mechanism for JSON-serializing 64-bit integers between client <-> server <-> database. kai zhu [email protected] > On 24 Jul 2018, at 5:56 AM, Jordan Harband <[email protected]> wrote: > > That, and that the existing builtins already impose those limitations - and > only `class` allows you to do those things, with them. > > On Mon, Jul 23, 2018 at 3:52 PM, Ben Wiley <[email protected] > <mailto:[email protected]>> wrote: > I see, so it's not that you can't do things without class as much as you can > impose limitations by using class. Thanks for clarifying > > Le lun. 23 juill. 2018 18 h 49, Jordan Harband <[email protected] > <mailto:[email protected]>> a écrit : > When extending builtins, `super()` is the only way you can get the > appropriate internal slots applied to the instance. (Private fields work the > same way by providing a matching guarantee - that the only way someone can > subclass you successfully is using `class extends` and `super`) > > On Mon, Jul 23, 2018 at 3:43 PM, Ben Wiley <[email protected] > <mailto:[email protected]>> wrote: > What exactly can be accomplished with super that can't be accomplished > otherwise? I know the transpiled code is very verbose and unintuitive to read > if you avoid explicitly naming the base class, but I wasn't aware of new > capabilities that were previously impossible. > > Ben > > > Le lun. 23 juill. 2018 18 h 06, Ranando King <[email protected] > <mailto:[email protected]>> a écrit : > Granted about `super()`. That's the one thing I can't easily reproduce. > However, barring those internal slots, I can reproduce the functionality of > `super` and the checks performed as a result of the internal slots, all in > ES6. As for built-ins, I can easily and properly extend builtins without > `class` since ES6 officially has `Object.setPrototypeOf()`. If you don't > think it's possible, you should take a close look at what I'm doing in the > repl.it <http://repl.it/> link from my first post. > > As for whether or not the sugary nature of `class` is a good thing, it really > is a matter of opinion. I just happen to be of the persuasion that since > there's literally no construct that `class` can produce that I cannot > reproduce by other means, then that means the `class` keyword (even in light > of `super`) is little more than syntactic sugar. As such, we shouldn't be so > hasty to turn an Object Oriented Prototype Based language into an Object > Oriented Class Based language. The only way to do that reasonably is to > ensure that whatever you can construct with `class` can always be > equivalently constructed without it. > > Here's a more logical argument instead. Even if there are subtle differences > between `class` constructors and object factory functions, providing an > isolated path specific to `class` is likely to lead to situations very > similar to what happens when an open source package gets forked. Eventually, > the difference between the two paths may become so great that one is > eventually abandoned (by developers) in favor of the other. This is only a > valid argument because the power of ES is in it's simplicity. It's like > building a house with wood, nails, sheetrock, etc... (JS) vs. building a > house with pre-fabricated parts (class-based languages). > > Don't get me wrong. The `class` keyword is a great thing. It simplifies the > production of creating object factories with prototypes. As I understand it, > that was the purpose. Let's not make the mistake of allowing something to be > done with `class` that cannot be reasonably reproduced without it. The moment > we do that, we're diverging from the intended purpose of `class`. > > > > On Mon, Jul 23, 2018 at 4:17 PM Jordan Harband <[email protected] > <mailto:[email protected]>> wrote: > Extend builtins, in particular - ie, `super()` allows your subclass to obtain > internal slots it can't otherwise get. > > Even if `class` were just sugar, I don't think I see the argument that that's > a *good* thing to preserve. > > On Mon, Jul 23, 2018 at 2:05 PM, Ranando King <[email protected] > <mailto:[email protected]>> wrote: > > > ---------- Forwarded message --------- > From: Ranando King <[email protected] <mailto:[email protected]>> > Date: Mon, Jul 23, 2018 at 4:04 PM > Subject: Re: proposal: Object Members > To: <[email protected] <mailto:[email protected]>> > > > You've made that argument before. Exactly what is it in ES6 that you **can** > do with `class` that you cannot do without class? I'd like some clarification > on this. > > On Mon, Jul 23, 2018 at 3:30 PM Jordan Harband <[email protected] > <mailto:[email protected]>> wrote: > `class` is already not just syntactic sugar, so that notion isn't correct, > and shouldn't be maintained. > > On Mon, Jul 23, 2018 at 12:38 PM, Ranando King <[email protected] > <mailto:[email protected]>> wrote: > I've written up a new draft proposal based on my own work with ES5 & ES6 > compatible classes with fields. That can be found > [here](https://github.com/rdking/proposal-object-members > <https://github.com/rdking/proposal-object-members>). I'm already aware of > the class-members proposal, but I think it breaks far to many things and > doesn't do anything to maintain the notion that "`class` is just syntactic > sugar". > > This proposal is specifically based on the code > [here](https://github.com/rdking/Class.js/tree/master/es6c > <https://github.com/rdking/Class.js/tree/master/es6c>). I've also got a > [repl.it > <http://repl.it/>](https://repl.it/@arkain/Classjs-Compact-Syntax-ES6 > <https://repl.it/@arkain/Classjs-Compact-Syntax-ES6>) that shows the same > code running. > > The idea behind the proposal is that instead of injecting a lot of new logic > into how `class` works, let's allow `class` to remain syntactic sugar, and > put that extra ability into object declarations instead. Then simply allow > `class` to do the same with it's own prototypes. > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
