Discuss
  • Class Syntax Proposal, Complete With Arguments For and Examples.

Class Syntax Proposal, Complete With Arguments For and Examples.

# Jonathan Dumaine (14 years ago)

I would like to add my suggestion for js classes.

gist.github.com/1224324

The key points are:

  • Constructors are functions named the same as the class.
  • Inside the class, this refers to the class instance.
  • Functions and variables are declared outside the constructor, inside the class block.
  • function and var keywords are optional after private or public keywords.
  • Getters, Setters are optional, but often useful. My example could be very concise after removing comments, spacing and getters/setters.
  • When compiled & minified, this syntax would be nearly equivalent to the current proposal (size-wise).

Arguments & Warrant:

This form would be very recognizable to people familiar with classical object oriented languages, yet it still maintains javascript's dynamic nature and prototypal inheritance. Almost everything in this form of class could be compiled to a prototypal form.

I also argue that this form of class is far more readable, which is a very important trait as javascript applications become ever larger and more complicated as the web evolves.

Lastly, I definitely have to veto the private @ syntax as posted in Brendan's TXJS slides. Apparently M. Night is also on the ECMA committee, because having symbols act as both operators and special, prefixed accessors would be quite a twist. :)

Jonathan Dumaine +1 50.55.10.11.12

# Mark S. Miller (14 years ago)

Your class recapitulates a mistake the committee almost made as well. Your private and public member are in the same namespace. Private members should not affect the behavior of the public API. However, if a class makes an extensible instance, and a client of the instance tries to add an "_x" expando property to that instance, where that happens to conflict with one of that abstraction's private names, what should happen?

# Jonathan Dumaine (14 years ago)

Hello Mark,

I think mistake is a harsh word. It is really a question of how much the community wants javascript to adopt object-oriented paradigms. You could go all the way and make classes a very strict subset of the language: throw an error if the user tries to set a property of a class instance that has already been declared private. Or, on the complete opposite side of the spectrum: setting the property on an instance overwrite it, just like it would if the class instance was a normal object.

I would personally prefer the prior route: sacrifice some of javascript's dynamic attributes in favor of better abstraction and encapsulation capabilities. Of course, we're only talking about class instances here, so I think that's a very small sacrifice to be made.

Perhaps you could direct me to the discussion the committee has already had on this matter so I could better form my arguments?

Jonathan Dumaine +1 50.55.10.11.12

# Mike Shaver (14 years ago)

On Sun, Sep 18, 2011 at 1:36 AM, Jonathan Dumaine <jonathan.dumaine at dumstruck.com> wrote:

You could go all the way and make classes a very strict subset of the language: throw an error if the user tries to set a property of a class instance that has already been declared private [...] I would personally prefer the prior route: sacrifice some of javascript's dynamic attributes in favor of better abstraction and encapsulation capabilities.

But one problem here is exactly related to abstraction and encapsulation: the class's implementation can't add a new private property without risking breaking of existing clients: if they were using the newly-claimed name as an "expando" property's name, then the changes to the "encapsulated and abstracted" internal representation will cause them to error out.

Mike

# Mark S. Miller (14 years ago)

On Sat, Sep 17, 2011 at 10:36 PM, Jonathan Dumaine < jonathan.dumaine at dumstruck.com> wrote:

Hello Mark,

I think mistake is a harsh word.

My apologies if it came across as harsh. I did not intend harshness, quite that opposite. That's why I mentioned that the committee almost made the same mistake -- to let you know you were in good company.

[...]

Perhaps you could direct me to the discussion the committee has already had on this matter so I could better form my arguments?

It was brief and verbal. It may have been captured in the meeting notes. But I don't think there's much more to say on this particular matter than what I've said. I don't think much more was said at the time.