Is class syntax really necessary ?

Alex Russell alex at dojotoolkit.org
Mon May 23 10:03:24 PDT 2011


On May 23, 2011, at 8:31 AM, Brendan Eich wrote:

> On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
>> On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
>> 
>>> On 23.05.2011 14:17, Irakli Gozalishvili wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I think there lot's of proposals for ES.next that require syntax extensions, which is probably worth if new functionality added or shortens most commonly used constructs like functions (were no other option is available). In case of this proposal: http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues even though
>>>> I like it I'm not sure adding new syntax is worth it.
>>>> 
>>> 
>>> May I ask a counter question -- why do you think it's not good to add syntactic sugar for classes? It's a kind of a strange thing. People sometimes talk about unnecessarily of a sugar. But why I'm asking? Is it bad to use a sugar? Or do you _really_ worry about an _implementation_ that e.g. a language will be "too heavy"? After all, it's not even the issue of users, it's the issue of implementers.
>>> 
>> Dimitry thanks that's very good question.
>> 
>> 1. More syntax means larger language surface, which adds complexity more things to remember / learn. More things to consider in ES.next.next 
> 
> It's true, although not everyone learns it all up front. Especially where new syntax is not yet supported in all browsers, and the student is not using a compiler to translate new to old version.
> 
> I think the sharper version of your (1) is: "class syntax is too much syntax to solve the problems people have with prototypal inheritance: subclassed prototype/constructor set-up and super calls."
> 
> I agree with that. Allen had been proposing super support that was separate. You proposed Function.prototype.extend. Perhaps there's enough there to relieve us of the large, tradition-haunted ediface of classes.
> 
> 
>> 2. I OOP in JS is already confusing for people coming from other languages, this proposal will make it even more confusing.
> 
> This is not as on target, in my opinion, because even if overwrought, classes are trying to solve some confusion or accident hazards in JS today to-do with prototypal inheritance. Namely,
> 
> (A) the boilerplate needed to set up a sub-prototype object with correct constructor property, and
> 
> (B) the pain of doing correct super calls by hand.

I hope we can add the hazards of incorrectly adding mutable state to a prototype and not an instance to this list. I.e., many people get this wrong:

function C(){
  // should include:
  //   this._list = [];
}
C.prototype = {
  _list: [],
  addToList: function(item) {
    this._list.push(item);    // logic error!
    // side-effects here
  }
};

Allen and I have discussed this before, so it's not a surprise, but I'm worried that some proposals might omit fixing this on their todo list.

> Can we agree that these are problems to be solved, if not by classes then by other APIs or special forms?
> 
> /be
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

--
Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723



More information about the es-discuss mailing list