> 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 < andrea.giammar...@gmail.com> 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 <king...@gmail.com> 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 < >> andrea.giammar...@gmail.com> 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 <king...@gmail.com> 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 <ljh...@gmail.com> >>>> 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 < >>>>> tj.crow...@farsightsoftware.com> wrote: >>>>> >>>>>> On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot >>>>>> <michael.lee.ther...@gmail.com> 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 >>>>> 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
