On Monday, 2011-05-23 at 18:47 , John Lenz wrote: > 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. If there will be build-in `Function.prototype.extend` it will be pretty easy to teach closure compiler to take advantage of that. > > On Mon, May 23, 2011 at 4:10 AM, Dmitry A. Soshnikov > <[email protected]> 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_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 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 > > > > > > _______________________________________________ es-discuss mailing list > > > [email protected] https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
