On Monday, 2011-05-23 at 17:31 , 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. > > Can we agree that these are problems to be solved, if not by classes then by > other APIs or special forms? I do completely agree with that! > > /be >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
