Minimalist (why) classes ?

Brendan Eich brendan at mozilla.com
Fri Nov 11 18:38:28 PST 2011


On Nov 11, 2011, at 5:02 PM, Irakli Gozalishvili <rfobic at gmail.com> wrote:

> What I'm suggesting is to sugar

Sugar usually means new syntax, not methods, but no worries.


> current patterns, without adding new syntax similar to how Funciton.prototype.bind was added.

That ES5 addition was years late, a bit different from the de-facto standard, and it is still verbose and a bit hard to optimize compared to lexical-only |this| forms such as block lambdas.

Still good to have, but we are not operating under ES3.1's artificial "no new syntax" regime.


> And maybe in next iteration add special syntax if it still we be wanted.

Iterations take 3 years anyway, no savings and potentially big tax on community.


> 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.

No, it is not easy to fix anything once standardized.

Having written all this, I will repeat that I like your selfish work and the exemplar idea, and I would not want over-minimal classes instead or alongside. Minimizing too much defeats the purpose of adding class syntax. Hence my desire for batteries and leather included.


> 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. 

Not if classes also provide statics, privates, constructor(@x, @y) {} shorthand, etc.


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

Not the semantics, though. That is the point of desugaring.

Getting the syntax right, or not adding it till we do, is still required.

/be

> 
> 
> Regards
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
> Address: 29 Rue Saint-Georges, 75009 Paris, France
> 
> 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
>>> 
>>> 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> 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
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111111/3e6af02d/attachment.html>


More information about the es-discuss mailing list