proposal: Object Members

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

proposal: Object Members

Ranando King
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Jordan Harband
`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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Fwd: proposal: Object Members

Ranando King


---------- Forwarded message ---------
From: Ranando King <[hidden email]>
Date: Mon, Jul 23, 2018 at 4:04 PM
Subject: Re: proposal: Object Members
To: <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Jordan Harband
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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Ranando King <[hidden email]>
Date: Mon, Jul 23, 2018 at 4:04 PM
Subject: Re: proposal: Object Members
To: <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Ranando King
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 <[hidden email]> 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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Ranando King <[hidden email]>
Date: Mon, Jul 23, 2018 at 4:04 PM
Subject: Re: proposal: Object Members
To: <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Ben Wiley
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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Ranando King <[hidden email]>
Date: Mon, Jul 23, 2018 at 4:04 PM
Subject: Re: proposal: Object Members
To: <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Jordan Harband
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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Ranando King <[hidden email]>
Date: Mon, Jul 23, 2018 at 4:04 PM
Subject: Re: proposal: Object Members
To: <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Ben Wiley
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Ranando King <[hidden email]>
Date: Mon, Jul 23, 2018 at 4:04 PM
Subject: Re: proposal: Object Members
To: <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Jordan Harband
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Ranando King <[hidden email]>
Date: Mon, Jul 23, 2018 at 4:04 PM
Subject: Re: proposal: Object Members
To: <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: proposal: Object Members

Darien Valentine
In reply to this post by Ranando King
> That, and that the existing builtins already impose those limitations - and only class allows you to do those things, with them.

I’m surprised by that statement — it appeared to me that it currently remains possible to create classes, including classes that extend built-ins, with class syntax.

```
const test = value => {
  if (typeof value !== 'string') throw new TypeError('nope');
  return value;
};

function StringSet(init) {
  if (new.target === undefined)
    throw new TypeError('StringSet is not a constructor');
  if (init !== undefined)
    init = Array.from(init, test);

  return Reflect.construct(Set, [ init ], new.target);
}

Reflect.defineProperty(StringSet.prototype, 'add', {
  configurable: true,
  value: Object.setPrototypeOf({
    add(value) {
      return super.add(test(value));
    }
  }, Set.prototype).add
});

Reflect.defineProperty(StringSet.prototype, Symbol.toStringTag, {
  configurable: true,
  value: 'StringSet'
});

Reflect.setPrototypeOf(StringSet, Set);
Reflect.setPrototypeOf(StringSet.prototype, Set.prototype);

new StringSet('abc');
```

Not that this is something one is apt to want to do normally, though it being possible does remain useful sometimes for meta/compositiony stuff. It cannot be achieved in an <= ES5 environment, but it seems all the reflection tools needed are present in environments that actually have class syntax — even, despite the awkwardness necessitated by HomeObject stuff, what is needed to employ super in methods.

I’m curious if, aside from the possibility of implementation-specific things like type error messages being different, there there is anything about the above class which ends up observably different from the ES-side from one created with class syntax instead?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

kai zhu
In reply to this post by Jordan Harband
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.


On 24 Jul 2018, at 5:56 AM, Jordan Harband <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Ranando King <[hidden email]>
Date: Mon, Jul 23, 2018 at 4:04 PM
Subject: Re: proposal: Object Members
To: <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Michael Theriot
In reply to this post by Jordan Harband
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.

`Reflect.construct` allows subclasses to obtain internal slots without `super()` / class syntax.

```js
const SubDate = function (...args) {
  const instance = Reflect.construct(Date, args, SubDate);
  return instance;
};

Object.setPrototypeOf(SubDate.prototype, Date.prototype);

const sub = new SubDate();
sub.getDate(); // has internal slots, does not throw
sub instanceof SubDate; // true
sub instanceof Date; // true
```

This is the first I have heard `class` is anything but sugar.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

T.J. Crowder-2
On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
<[hidden email]> wrote:
> `Reflect.construct` allows subclasses to obtain internal slots without
> `super()` / class syntax.

Indeed, Darien pointed that out as well (and if you two hadn't, I would have. :-)

> This is the first I have heard `class` is anything but sugar.

The accurate statement would be that `class` lets you do things you couldn't do in ES5. But so does `Reflect.construct`. I believe it was important to the "no `new`" crowd that a non-`class` mechanism existed for creating objects using Error and Array as prototypes.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Jordan Harband
As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6. Thanks for providing clear code examples of how one might extend builtins without `class`.

@kai: yes, extending builtins makes sense, in that it's an important part of ES6. Invoking "the web" doesn't negate *any* of the features of the language, new or old. Separately, not every web use involves any JSON serialization in either direction.

On Tue, Jul 24, 2018 at 12:15 AM, T.J. Crowder <[hidden email]> wrote:
On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
<[hidden email]> wrote:
> `Reflect.construct` allows subclasses to obtain internal slots without
> `super()` / class syntax.

Indeed, Darien pointed that out as well (and if you two hadn't, I would have. :-)

> This is the first I have heard `class` is anything but sugar.

The accurate statement would be that `class` lets you do things you couldn't do in ES5. But so does `Reflect.construct`. I believe it was important to the "no `new`" crowd that a non-`class` mechanism existed for creating objects using Error and Array as prototypes.

-- T.J. Crowder


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Ranando King
@ljharb: It seems you now understand what I was trying to say. Sadly, I'm not always the most eloquent.

 As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6.

The intent of my proposal is to provide both member fields and privilege levels to the `class` keyword, and the equivalent for object literals in a way that meets with both an intuitive declaration style, and a reasonable access notation that breaks as little as few as possible of the developers expectations of what can and can't be done.

On Tue, Jul 24, 2018 at 3:18 AM Jordan Harband <[hidden email]> wrote:
As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6. Thanks for providing clear code examples of how one might extend builtins without `class`.

@kai: yes, extending builtins makes sense, in that it's an important part of ES6. Invoking "the web" doesn't negate *any* of the features of the language, new or old. Separately, not every web use involves any JSON serialization in either direction.

On Tue, Jul 24, 2018 at 12:15 AM, T.J. Crowder <[hidden email]> wrote:
On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
<[hidden email]> wrote:
> `Reflect.construct` allows subclasses to obtain internal slots without
> `super()` / class syntax.

Indeed, Darien pointed that out as well (and if you two hadn't, I would have. :-)

> This is the first I have heard `class` is anything but sugar.

The accurate statement would be that `class` lets you do things you couldn't do in ES5. But so does `Reflect.construct`. I believe it was important to the "no `new`" crowd that a non-`class` mechanism existed for creating objects using Error and Array as prototypes.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Andrea Giammarchi-2
Private fields also won't work as expected and the mandatory super call in constructor is also different from ES5. Let's add species and special class related Symbol so that it makes no sense to define classes "just sugar" + there's no point in avoiding classes at all costs when any of these features is needed.

Regards

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason


On Tue, Jul 24, 2018 at 4:15 PM Ranando King <[hidden email]> wrote:
@ljharb: It seems you now understand what I was trying to say. Sadly, I'm not always the most eloquent.

 As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6.

The intent of my proposal is to provide both member fields and privilege levels to the `class` keyword, and the equivalent for object literals in a way that meets with both an intuitive declaration style, and a reasonable access notation that breaks as little as few as possible of the developers expectations of what can and can't be done.

On Tue, Jul 24, 2018 at 3:18 AM Jordan Harband <[hidden email]> wrote:
As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6. Thanks for providing clear code examples of how one might extend builtins without `class`.

@kai: yes, extending builtins makes sense, in that it's an important part of ES6. Invoking "the web" doesn't negate *any* of the features of the language, new or old. Separately, not every web use involves any JSON serialization in either direction.

On Tue, Jul 24, 2018 at 12:15 AM, T.J. Crowder <[hidden email]> wrote:
On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
<[hidden email]> wrote:
> `Reflect.construct` allows subclasses to obtain internal slots without
> `super()` / class syntax.

Indeed, Darien pointed that out as well (and if you two hadn't, I would have. :-)

> This is the first I have heard `class` is anything but sugar.

The accurate statement would be that `class` lets you do things you couldn't do in ES5. But so does `Reflect.construct`. I believe it was important to the "no `new`" crowd that a non-`class` mechanism existed for creating objects using Error and Array as prototypes.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Ranando King
Private fields also won't work as expected...

Can you clarify what you're referring to? I've created a library that essentially implements the functional parts of what I intend with this proposal. Of course the syntax isn't the same, and Proxy was used to create a membrane between the public and private storage, and I can't prevent that proxy from being passed to external functions, but those are ES-specific implementation details and not how it would be implemented in the engine.

 ... the mandatory super call in constructor is also different from ES5.

You shouldn't really try to compare ES5 and ES6. My statement that "`class` is syntactic sugar" refers to the fact that anything you can do with `class` in ES6 can also be done without `class` in ES6.

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason.

Just because `class` is essentially syntactic sugar doesn't mean that the desugaring is backwards compatible with older versions of the language. I do not wish to imply that. Nor do I see the need to make such a statement true. Such an attempt to enforce backwards compatibility to that degree would prove excessively burdensome on the process of improving and adding features to the language.

On Tue, Jul 24, 2018 at 9:41 AM Andrea Giammarchi <[hidden email]> wrote:
Private fields also won't work as expected and the mandatory super call in constructor is also different from ES5. Let's add species and special class related Symbol so that it makes no sense to define classes "just sugar" + there's no point in avoiding classes at all costs when any of these features is needed.

Regards

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason


On Tue, Jul 24, 2018 at 4:15 PM Ranando King <[hidden email]> wrote:
@ljharb: It seems you now understand what I was trying to say. Sadly, I'm not always the most eloquent.

 As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6.

The intent of my proposal is to provide both member fields and privilege levels to the `class` keyword, and the equivalent for object literals in a way that meets with both an intuitive declaration style, and a reasonable access notation that breaks as little as few as possible of the developers expectations of what can and can't be done.

On Tue, Jul 24, 2018 at 3:18 AM Jordan Harband <[hidden email]> wrote:
As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6. Thanks for providing clear code examples of how one might extend builtins without `class`.

@kai: yes, extending builtins makes sense, in that it's an important part of ES6. Invoking "the web" doesn't negate *any* of the features of the language, new or old. Separately, not every web use involves any JSON serialization in either direction.

On Tue, Jul 24, 2018 at 12:15 AM, T.J. Crowder <[hidden email]> wrote:
On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
<[hidden email]> wrote:
> `Reflect.construct` allows subclasses to obtain internal slots without
> `super()` / class syntax.

Indeed, Darien pointed that out as well (and if you two hadn't, I would have. :-)

> This is the first I have heard `class` is anything but sugar.

The accurate statement would be that `class` lets you do things you couldn't do in ES5. But so does `Reflect.construct`. I believe it was important to the "no `new`" crowd that a non-`class` mechanism existed for creating objects using Error and Array as prototypes.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Andrea Giammarchi-2
> Proxy was used to create a membrane between the public and private storage, and I can't prevent that proxy from being passed to external functions

this already underlines what I mean: classes are not just syntactic sugar because you cannot replicate what they do, not even using ES6.

having privates / proxies maybe exposed is not how I'd personally code.



On Tue, Jul 24, 2018 at 5:15 PM Ranando King <[hidden email]> wrote:
Private fields also won't work as expected...

Can you clarify what you're referring to? I've created a library that essentially implements the functional parts of what I intend with this proposal. Of course the syntax isn't the same, and Proxy was used to create a membrane between the public and private storage, and I can't prevent that proxy from being passed to external functions, but those are ES-specific implementation details and not how it would be implemented in the engine.

 ... the mandatory super call in constructor is also different from ES5.

You shouldn't really try to compare ES5 and ES6. My statement that "`class` is syntactic sugar" refers to the fact that anything you can do with `class` in ES6 can also be done without `class` in ES6.

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason.

Just because `class` is essentially syntactic sugar doesn't mean that the desugaring is backwards compatible with older versions of the language. I do not wish to imply that. Nor do I see the need to make such a statement true. Such an attempt to enforce backwards compatibility to that degree would prove excessively burdensome on the process of improving and adding features to the language.

On Tue, Jul 24, 2018 at 9:41 AM Andrea Giammarchi <[hidden email]> wrote:
Private fields also won't work as expected and the mandatory super call in constructor is also different from ES5. Let's add species and special class related Symbol so that it makes no sense to define classes "just sugar" + there's no point in avoiding classes at all costs when any of these features is needed.

Regards

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason


On Tue, Jul 24, 2018 at 4:15 PM Ranando King <[hidden email]> wrote:
@ljharb: It seems you now understand what I was trying to say. Sadly, I'm not always the most eloquent.

 As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6.

The intent of my proposal is to provide both member fields and privilege levels to the `class` keyword, and the equivalent for object literals in a way that meets with both an intuitive declaration style, and a reasonable access notation that breaks as little as few as possible of the developers expectations of what can and can't be done.

On Tue, Jul 24, 2018 at 3:18 AM Jordan Harband <[hidden email]> wrote:
As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6. Thanks for providing clear code examples of how one might extend builtins without `class`.

@kai: yes, extending builtins makes sense, in that it's an important part of ES6. Invoking "the web" doesn't negate *any* of the features of the language, new or old. Separately, not every web use involves any JSON serialization in either direction.

On Tue, Jul 24, 2018 at 12:15 AM, T.J. Crowder <[hidden email]> wrote:
On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
<[hidden email]> wrote:
> `Reflect.construct` allows subclasses to obtain internal slots without
> `super()` / class syntax.

Indeed, Darien pointed that out as well (and if you two hadn't, I would have. :-)

> This is the first I have heard `class` is anything but sugar.

The accurate statement would be that `class` lets you do things you couldn't do in ES5. But so does `Reflect.construct`. I believe it was important to the "no `new`" crowd that a non-`class` mechanism existed for creating objects using Error and Array as prototypes.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Michael Theriot
What can classes do that ES6 can't?

On Tuesday, July 24, 2018, Andrea Giammarchi <[hidden email]> wrote:
> Proxy was used to create a membrane between the public and private storage, and I can't prevent that proxy from being passed to external functions

this already underlines what I mean: classes are not just syntactic sugar because you cannot replicate what they do, not even using ES6.

having privates / proxies maybe exposed is not how I'd personally code.



On Tue, Jul 24, 2018 at 5:15 PM Ranando King <[hidden email]> wrote:
Private fields also won't work as expected...

Can you clarify what you're referring to? I've created a library that essentially implements the functional parts of what I intend with this proposal. Of course the syntax isn't the same, and Proxy was used to create a membrane between the public and private storage, and I can't prevent that proxy from being passed to external functions, but those are ES-specific implementation details and not how it would be implemented in the engine.

 ... the mandatory super call in constructor is also different from ES5.

You shouldn't really try to compare ES5 and ES6. My statement that "`class` is syntactic sugar" refers to the fact that anything you can do with `class` in ES6 can also be done without `class` in ES6.

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason.

Just because `class` is essentially syntactic sugar doesn't mean that the desugaring is backwards compatible with older versions of the language. I do not wish to imply that. Nor do I see the need to make such a statement true. Such an attempt to enforce backwards compatibility to that degree would prove excessively burdensome on the process of improving and adding features to the language.

On Tue, Jul 24, 2018 at 9:41 AM Andrea Giammarchi <[hidden email]> wrote:
Private fields also won't work as expected and the mandatory super call in constructor is also different from ES5. Let's add species and special class related Symbol so that it makes no sense to define classes "just sugar" + there's no point in avoiding classes at all costs when any of these features is needed.

Regards

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason


On Tue, Jul 24, 2018 at 4:15 PM Ranando King <[hidden email]> wrote:
@ljharb: It seems you now understand what I was trying to say. Sadly, I'm not always the most eloquent.

 As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6.

The intent of my proposal is to provide both member fields and privilege levels to the `class` keyword, and the equivalent for object literals in a way that meets with both an intuitive declaration style, and a reasonable access notation that breaks as little as few as possible of the developers expectations of what can and can't be done.

On Tue, Jul 24, 2018 at 3:18 AM Jordan Harband <[hidden email]> wrote:
As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6. Thanks for providing clear code examples of how one might extend builtins without `class`.

@kai: yes, extending builtins makes sense, in that it's an important part of ES6. Invoking "the web" doesn't negate *any* of the features of the language, new or old. Separately, not every web use involves any JSON serialization in either direction.

On Tue, Jul 24, 2018 at 12:15 AM, T.J. Crowder <[hidden email]> wrote:
On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
<[hidden email]> wrote:
> `Reflect.construct` allows subclasses to obtain internal slots without
> `super()` / class syntax.

Indeed, Darien pointed that out as well (and if you two hadn't, I would have. :-)

> This is the first I have heard `class` is anything but sugar.

The accurate statement would be that `class` lets you do things you couldn't do in ES5. But so does `Reflect.construct`. I believe it was important to the "no `new`" crowd that a non-`class` mechanism existed for creating objects using Error and Array as prototypes.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: proposal: Object Members

Ranando King
In reply to this post by Andrea Giammarchi-2
> this already underlines what I mean: classes are not just syntactic sugar because you cannot replicate what they do, not even using ES6.

You're misunderstanding a few things.
1. Any ES6 class I create using the `class` keyword, I can recreate without the `class` keyword. Period. There's no exception to this.
2. What I was describing to you was the work I put in to create a `class` factory function that allows developers to easily create `class` instances with data fields of varying privilege. This work is the **_conceptual basis_** of my proposal. I never claimed even once that my example code was somehow a flawless implementation of my proposal. That would be expressly impossible. If it weren't, then I wouldn't be asking for a new feature. The fact that in ES6 I cannot prevent a developer from passing the proxied context object to an external method or assign it to an external variable is not an issue that would be suffered by an in engine implementation of my proposal. However, that would be a different version of ES, not ES6.

On Tue, Jul 24, 2018 at 10:29 AM Andrea Giammarchi <[hidden email]> wrote:
> Proxy was used to create a membrane between the public and private storage, and I can't prevent that proxy from being passed to external functions

this already underlines what I mean: classes are not just syntactic sugar because you cannot replicate what they do, not even using ES6.

having privates / proxies maybe exposed is not how I'd personally code.



On Tue, Jul 24, 2018 at 5:15 PM Ranando King <[hidden email]> wrote:
Private fields also won't work as expected...

Can you clarify what you're referring to? I've created a library that essentially implements the functional parts of what I intend with this proposal. Of course the syntax isn't the same, and Proxy was used to create a membrane between the public and private storage, and I can't prevent that proxy from being passed to external functions, but those are ES-specific implementation details and not how it would be implemented in the engine.

 ... the mandatory super call in constructor is also different from ES5.

You shouldn't really try to compare ES5 and ES6. My statement that "`class` is syntactic sugar" refers to the fact that anything you can do with `class` in ES6 can also be done without `class` in ES6.

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason.

Just because `class` is essentially syntactic sugar doesn't mean that the desugaring is backwards compatible with older versions of the language. I do not wish to imply that. Nor do I see the need to make such a statement true. Such an attempt to enforce backwards compatibility to that degree would prove excessively burdensome on the process of improving and adding features to the language.

On Tue, Jul 24, 2018 at 9:41 AM Andrea Giammarchi <[hidden email]> wrote:
Private fields also won't work as expected and the mandatory super call in constructor is also different from ES5. Let's add species and special class related Symbol so that it makes no sense to define classes "just sugar" + there's no point in avoiding classes at all costs when any of these features is needed.

Regards

P.S. Babel mistakenly sold classes as "just sugar" and never worked properly with Custom Elements and builtins extend until version 7 which is still not perfect but at least it doesn't throw errors for no reason


On Tue, Jul 24, 2018 at 4:15 PM Ranando King <[hidden email]> wrote:
@ljharb: It seems you now understand what I was trying to say. Sadly, I'm not always the most eloquent.

 As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6.

The intent of my proposal is to provide both member fields and privilege levels to the `class` keyword, and the equivalent for object literals in a way that meets with both an intuitive declaration style, and a reasonable access notation that breaks as little as few as possible of the developers expectations of what can and can't be done.

On Tue, Jul 24, 2018 at 3:18 AM Jordan Harband <[hidden email]> wrote:
As you've all pointed out, it's not "just sugar" in the sense that you couldn't do it in ES5; it's more that parallel syntax and API were created for the new functionality in ES6. Thanks for providing clear code examples of how one might extend builtins without `class`.

@kai: yes, extending builtins makes sense, in that it's an important part of ES6. Invoking "the web" doesn't negate *any* of the features of the language, new or old. Separately, not every web use involves any JSON serialization in either direction.

On Tue, Jul 24, 2018 at 12:15 AM, T.J. Crowder <[hidden email]> wrote:
On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
<[hidden email]> wrote:
> `Reflect.construct` allows subclasses to obtain internal slots without
> `super()` / class syntax.

Indeed, Darien pointed that out as well (and if you two hadn't, I would have. :-)

> This is the first I have heard `class` is anything but sugar.

The accurate statement would be that `class` lets you do things you couldn't do in ES5. But so does `Reflect.construct`. I believe it was important to the "no `new`" crowd that a non-`class` mechanism existed for creating objects using Error and Array as prototypes.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12