On Nov 11, 2011, at 4:09 PM, Irakli Gozalishvili wrote:

> Thats exact port of proposal that Jeremy wrote here:
> https://gist.github.com/1329619 
> 
> I could write add examples from the classes proposal if that wolud help:
> http://wiki.ecmascript.org/doku.php?id=harmony:classes

Maybe, but I think that you'd be beating a dead horse.

Class syntax is wanted to avoid some method calling boilerplate that's more 
verbose, arguably easier to get wrong, and harder to analyze and optimize. 
That's it.

Hence, "classes as sugar". If you find existing JS sweet enough, you won't want 
classes.

/be

> Regards
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
> Address: 29 Rue Saint-Georges, 75009 Paris, France
> 
> On Friday, 2011-11-11 at 16:05 , John J Barton wrote:
> 
>> On Fri, Nov 11, 2011 at 3:47 PM, Irakli Gozalishvili <rfo...@gmail.com> 
>> wrote:
>>> Hi,
>>> I have posted this to the long thread of "Minimalist Classes", but since I
>>> have not got any response, I assume it got lost into a long discussion. So I
>>> thought I'll give it another try on fresh thread.
>>> I do really liked direction that Jeremy tried to push classes to, but still
>>> I don't understand why do we need to introduce new syntax to the language.
>>> From what I can tell, lack of classes or special syntax for creating ones,
>>> is not a problem. Problem is amount of ceremony one needs to perform inherit
>>> or subclass if you like.
>>> Also, I think we don't need new `class` expression to solve actual problems
>>> we have, simple function will do the job perfectly here, also it will add
>>> zero learning curve! I forked Jeremy's proposal and modified it to ilustrate
>>> how existing subclassing problems can be solved without introducing new
>>> constructs to the language or adding more verbosity. Please also note that
>>> there is nothing new here, lot's of frameworks do this already (hide
>>> prototype machinery), but each does it with it's own flavored API which is
>>> IMO another problem that standardization should solve. The classes problem
>>> is very similar to `Function.prototype.bind` that ES5 solved greatly, why
>>> not do the same for classes ?
>>> https://gist.github.com/1355701
>> 
>> Just FYI,
>> 
>> I found the listing confusing, since the examples seem unrelated to
>> each other and there is no reference to the corresponding 'class'
>> proposal.
>> 
>> jjb
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to