Is class syntax really necessary ?

Juan Ignacio Dopazo dopazo.juan at gmail.com
Mon May 23 09:39:19 PDT 2011


On Mon, May 23, 2011 at 10:11 AM, Irakli Gozalishvili <rfobic at gmail.com>
 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110523/ab75e9f6/attachment.html>


More information about the es-discuss mailing list