Hi, Sorry have not had a chance to reply on this thread earlier. I do really like the direction that Jeremy pushes to, but still I don't understand why do we need to introduce new syntax to the language. I think `class` expression is completely unnecessary, why not a function ? I forked Jeremy's proposal and modified it so that it preserves it's simplicity without introducing any new syntax to the language:
https://gist.github.com/1355701 In addition I changed few things that was raising additional questions: - `constructor` property as initializer (what if constructor is shared, frozen etc). I also intentionally omitted `super` as it's separate topic. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu) On Thursday, 2011-11-03 at 11:33 , Brendan Eich wrote: > On Nov 3, 2011, at 6:53 AM, Matthew Tretter wrote: > > > Sorry, I'll try to be more clear. > > > > What's "super-intuitive" isn't *that* you use the form "class name expr", > > it's how you interact with that form once you know what it does. The reason > > is self-evident—people know how to work with object literals and functions. > > Then we are not talking about the same thing. > > Class syntax of the form class C {...} where the {...} is an extension of > ES3-5 ObjectLiteral syntax is fine, we're aligned on that (for the moment). > > The particular form from Jeremy's gist: > > // Note that the right-hand side of a class definition is just an expression, > // an object literal is not required. You can be fully dynamic when creating a > // class: > > class Student objectContainingStudentProperties > line 59 on at https://gist.github.com/1329619 > > is what is at issue. > > > > This is not true of the Leather form which, like I said, would probably > > inspire a lot of "run(a){…}" attempts at function definitions in non-class > > contexts. > > Different topic yet again, but ok: method definition syntax was already > proposed a while ago by Allen, and promoted to Harmony for ES.next. It may > cause some Dart-like 'function'-lacking misplaced method definition attempts, > indeed. We should see how big a problem this is in practice. I doubt it'll be > more than a speed-bump for some, but if it is, we can adapt. > > > > Not that that alone is enough to disqualify it, but it's something that > > should be taken into consideration. > > Agreed. > > > > Off the top of my head, one use-case would be Python-like method decorators: > > > > class Runner { > > run: require_auth(function(a) { > > }) > > } > > > > Another would be the dynamic definition of methods: > > > > class Runner { > > run: (function() { > > return someFeatureIsSupported ? feature : polyfill; > > })() > > } > > > > > These are still legal, with class body built on extended object literals. Why > did you think these would be verboten? > > It's one thing to say "these should work". It's another to insist that the > long-hand should be the only way. > > /be > _______________________________________________ > es-discuss mailing list > [email protected] (mailto:[email protected]) > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
