Is class syntax really necessary ?

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Mon May 23 04:10:15 PDT 2011


On 23.05.2011 14:17, Irakli Gozalishvili wrote:
> Hi,
>
> I think there lot's of proposals for ES.next that require syntax 
> extensions, which is probably worth if new functionality added or 
> shortens most commonly used constructs like functions (were no other 
> option is available). In case of this proposal: 
> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues 
> even though
> I like it I'm not sure adding new syntax is worth it.
>

May I ask a counter question -- why do you think it's not good to add 
syntactic sugar for classes? It's a kind of a strange thing. People 
sometimes talk about unnecessarily of a sugar. But why I'm asking? Is it 
bad to use a sugar? Or do you _really_ worry about an _implementation_ 
that e.g. a language will be "too heavy"? After all, it's not even the 
issue of users, it's the issue of implementers.

That is, since it's just a sugar, the users _still_ are free to use 
_desugared_ constructions (i.e. constructor + prototype + manual linkage 
of parent prototype in case of inheritance). If they want to. If they 
instead want to write with the sugar -- why we should worry about that 
"adding of new syntax is worth" (taking into account that `class`, 
`extends`, etc. keywords are already reserved since ES3 era).

So from what I can tell, right after the sugar for classes is 
standardized, everyone will just start to use it and forget about 
desugared constructions. And nobody even will think and bother about 
whether it's worth or not.

A good point of standardizing this "wrapper" (which is just a sugar) is 
that all ad-hoc class-wrappers of libraries will be just eliminated and 
there will be common classes sugar "from the box". Since JS already 
supports classical inheritance (though, without sugar), I don't how it's 
bad not to standardize the sugar for it. It will be convenient who need 
to program a class-based system. At the same time, if someone will still 
need a "chaotic code reuse", i.e. a prototype-based inheritance ("reuse 
a code from that object from which I want") -- they still be able to use 
things as `Object.create` (or <| operator, etc.)

> I'm not suggesting that sugar for class composition is not necessary, 
> example from three.js 
> <https://github.com/mrdoob/three.js/blob/master/src/objects/SkinnedMesh.js> used 
> by proposal highlights necessity pretty very well, I'm just thinking 
> of doing that without introducing new syntax, here is one 
> option: https://gist.github.com/986487
>
> This way syntax noise may be reduced in addition this can be shimmed 
> into current JS by implementing `Function.prototype.extend`.
>

Yeah, OTOH, it can be so too. Though, the _familiar_ sugar will be bring 
the ability to involve programmers quicker.

> Also every single frameworks today does something similar in one form 
> or another, IMO all is necessary is to have a standard that will let 
> bikeshedding go away.

Right.

Dmitry.

> I think there is also a good precedent of this with 
> `Function.prototype.bind`.
>
> Here are some related links:
>
> http://documentcloud.github.com/backbone/
> http://base2.googlecode.com/svn/version/1.0.2/doc/base2.html#/doc/!base2.Base
> http://prototypejs.org/learn/class-inheritance
> http://startdojo.com/2011/03/02/dojo-classes-inherited-and-constructors/
> http://mootools.net/docs/core/Class/Class
> http://ejohn.org/blog/simple-javascript-inheritance/
>
>
> Kind regards
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
> Address: 29 Rue Saint-Georges, 75009 Paris, France 
> <http://goo.gl/maps/3CHu>
>
>
> _______________________________________________
> 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/20110523/7c5ff915/attachment.html>


More information about the es-discuss mailing list