Is class syntax really necessary ?

John Lenz concavelenz at gmail.com
Mon May 23 09:47:38 PDT 2011


The class syntax would be a great boon to the Closure Compiler.  Much of
ADVANCED mode optimizations depends on understanding class relationships,
currently this means "teaching" it about each framework's "extend" or
"inherit" methods and each of their subtleties.

On Mon, May 23, 2011 at 4:10 AM, Dmitry A. Soshnikov <
dmitry.soshnikov at gmail.com> wrote:

>  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_issueseven 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 listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> 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/023df036/attachment-0001.html>


More information about the es-discuss mailing list