Minimalist Classes

[Axel Rauschmayer]

The new more object-literal-style syntax is great. "private" sticks out a bit, but it’s not a deal-breaker. It could even be good for the code if it had to appear at the beginning (kind of like a section). Such a section would be great for object literals, too. Maybe we can find a syntax that works for both (as in future-friendly)!

>> And if we're trying to emulate classical OO, then how about just dropping the ability to define data properties on the prototype.
> 
> I am all for that! I kept it for parity with jashkenas's three.js example, but the r, g, and b props there are vacuous default proto-props (ditto the Monster example's proto var and const).

Great great idea! Very newbie-friendly. The error message could tell you: put those properties into the constructor.

>> Your private instance variables are quite interesting.
> 
> Yes, that is a missing ingredient in most proposals we've seen.

+1

>> One nit: you're using @ as both a sigil in @name and as an operator in other at name.  I would expect other. at name instead.
> 
> No, it's a prefix operator if in operand context (like / starting a regexp), a binary operator in operator context (/ as division).
> 
> Trying to avoid .@ all over, and this.@ noise.

I think people have certain expectations for how property access looks (and JavaScript is a better language for it; I don’t like how Java instance properties become part of the local scope). My guess: The expectation would be either one of two notations.

    this at name, other at name
    this. at name, other. at name

>> What about just a dot with nothing on the left hand side?  Can '.foo' be shorthand for 'this.foo'?  Or are there grammatical issues with that?
> 
> That could work with [no LineTerminator here] restriction on the left, which is awkward -- it mandates manual semicolon insertion of you assign .foo = bar after a baz() statement. We thought about this in consider how to reform with, but that's a dead end.
> 
> Another sigil is hard to justify for the this.publicProp case, and for dyadic methods, etc., other.publicProp is how you spell it -- the dot, I mean. So one would want this.publicProp anyway. Between this consideration and the preference for private, I'm fine stopping with @ for private.


I think the namespacing via this is a feature, it give the code a nice uniform look:
    if (this.foo === other.foo)

Axel

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111102/32ce65ec/attachment-0001.html>