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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
