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 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 <ljh...@gmail.com> 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 <king...@gmail.com> wrote: > >> >> >> ---------- Forwarded message --------- >> From: Ranando King <king...@gmail.com> >> Date: Mon, Jul 23, 2018 at 4:04 PM >> Subject: Re: proposal: Object Members >> To: <ljh...@gmail.com> >> >> >> 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 <ljh...@gmail.com> 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 <king...@gmail.com> >>> 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). 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). I've also got a [ >>>> repl.it](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 >>>> es-discuss@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
