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@name. I would expect other.@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@name, other@name
this.@name, other.@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
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
