proposal: Object Members

Tue Jul 24 06:31:53 UTC 2018

> 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
kaizhu256 at gmail.com

> On 24 Jul 2018, at 5:56 AM, Jordan Harband <ljharb at gmail.com> 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 <therealbenwiley at gmail.com <mailto:therealbenwiley at gmail.com>> 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 <ljharb at gmail.com <mailto:ljharb at gmail.com>> 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 <therealbenwiley at gmail.com <mailto:therealbenwiley at gmail.com>> 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 <kingmph at gmail.com <mailto:kingmph at gmail.com>> 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 <ljharb at gmail.com <mailto:ljharb at 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 <kingmph at gmail.com <mailto:kingmph at gmail.com>> wrote:
> 
> 
> ---------- Forwarded message ---------
> From: Ranando King <kingmph at gmail.com <mailto:kingmph at gmail.com>>
> Date: Mon, Jul 23, 2018 at 4:04 PM
> Subject: Re: proposal: Object Members
> To: <ljharb at gmail.com <mailto:ljharb at 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 <ljharb at gmail.com <mailto:ljharb at 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 <kingmph at gmail.com <mailto:kingmph at 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 <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
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> _______________________________________________
> 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/20180724/872df5d1/attachment-0001.html>