> 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
