Minimalist (why) classes ?

Irakli Gozalishvili rfobic at gmail.com
Fri Nov 11 17:02:36 PST 2011


What I'm suggesting is to sugar current patterns, without adding new syntax similar to how Funciton.prototype.bind was added. And maybe in next iteration add special syntax if it still we be wanted. It's just so much easier to fix `Object.extend` if it will end up to be a wrong fit than change a special class syntax.

BTW I have updated examples to illustrate exactly what is problematic requires sugar https://gist.github.com/1355701

Class syntax is wanted to avoid some method calling boilerplate that's more verbose, 

In my examples it actually takes same amount of chars:

class Foo extends Bar {}

VS

var Bar = Foo.extend({})

arguably easier to get wrong, and harder to analyze and optimize. That's it. 

Arguably indeed, IMO increasing surface of language makes surface of things that can be made wrong bigger, increasing probability of making things wrong. 


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Friday, 2011-11-11 at 16:31 , Brendan Eich wrote:

> 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 (http://goo.gl/maps/3CHu)
> > 
> > 
> > On Friday, 2011-11-11 at 16:05 , John J Barton wrote:
> > 
> > > On Fri, Nov 11, 2011 at 3:47 PM, Irakli Gozalishvili <rfobic at gmail.com (mailto:rfobic at 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 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/20111111/3183c1b5/attachment-0001.html>


More information about the es-discuss mailing list