Is class syntax really necessary ?
rfobic at gmail.com
Mon May 23 09:01:12 PDT 2011
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss