On Mon, May 23, 2011 at 10:11 AM, Irakli Gozalishvili <[email protected]> wrote:
> > On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov 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. > > Dimitry thanks that's very good question. > > 1. More syntax means larger language surface, which adds complexity > more things to remember / learn. More things to consider in ES.next.next > 2. I OOP in JS is already confusing for people coming from other languages, > this proposal will make it even more confusing. > > As a JS developer who works daily with the language, I can tell you that pretty much everyone I know that doesn't work exclusively with JavaScript hates the language (and are very emotional and vocal about it) because of: 1. The DOM 2. Prototype based inheritance And the reasons why they don't like prototype inheritance are: - They don't understand it. Chaining prototypes is not intuitive. This is solved by your Function.prototype.extend proposal. - The beginner examples around the web and their verbosity - The lack of keywords commonly found in other languages to refer to OOP concepts. At least in my country, this is a problem because 99% of the professional/high school training on programming is based on heavily typed OOP languages. The other reason for this situation is that JavaScript is mostly learned out of necessity, not choice. This means most JS users come from back-end experience (I saw a tweet a couple of days ago: "Mullet developer: strong back-end skills, weak front-end skills"), where they have a choice of platform. Most beginner examples start with: function Person(name) { this.name = name; } Person.prototype.speak = function () { /* ... */ } Person.prototype.walk = function() { /* ... */ } Most beginners react with "this sucks!" just based on the syntax, not because of the semantics. New syntax for constructor and prototypes would be very useful for beginners to learn gradually how to use the prototypical nature of the language, and for advanced programmers that use OOP to use what they already use with less noise. IMHO this is a case in which syntax reduces complexity. We also need to start writing better examples in our blogs and wikis. There is one aspect in which I do agree it can be more confusing. There are some keywords from other languages being reused in a completely different fashion. Mostly those related to property access privileges. Using "public" to refer to an instance property seems totally weird to me. Juan
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
