Minimalist Classes

Irakli Gozalishvili rfobic at gmail.com
Thu Nov 10 11:50:23 PST 2011


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
> es-discuss at mozilla.org (mailto: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/20111110/2bf87180/attachment.html>


More information about the es-discuss mailing list