proposal: Object Members
Michael Theriot
michael.lee.theriot at gmail.com
Tue Jul 24 16:01:33 UTC 2018
What can classes do that ES6 can't?
On Tuesday, July 24, 2018, Andrea Giammarchi <andrea.giammarchi at 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 <kingmph at 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.giammarchi at 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 <kingmph at 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 <ljharb at 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.crowder at farsightsoftware.com> wrote:
>>>>>
>>>>>> On Tue, Jul 24, 2018 at 8:00 AM, Michael Theriot
>>>>>> <michael.lee.theriot at 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 at mozilla.org
>>>>> 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/4d2c9878/attachment-0001.html>
More information about the es-discuss
mailing list