On 11/1/11 11:53 PM, Brendan Eich wrote:
On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
1) Class bodies are new syntax, so you can introduce new keywords,
right? So 'prop' or 'proto'? 'static' puts a property on the class.
'private' puts a (private) property on the instance. So 'proto'
could put a property on the prototype.
Yes, but prefix keywords in front of every member? Too heavy. Labeled
sections are problematic grammatically and most on TC39 hate 'em.
prefixed braced sub-bodies over-indent.
There ought to be a sane unprefixed default. Then, though, we still
have two choices:
(a) Data property initialiser syntax (x: v with comma separator).
(b) Assignment expression form (x = v with semicolon separator or
terminator and some kind of ASI consistency).
Neither is great. I lean toward (b). You?
I don't see why you can't use var syntax but with 'proto' as the keyword
instead of 'var':
// All instances inherit these default values:
proto x = 0, y = 0;
Similarly for static members as well:
static const ORIGIN = new Point(0,0), ONE = new Point(1,0);
Of course, that takes you away from unification with object literals
again... Though I don't think unifiying class bodies and object
literals was one of your original goals.
Your private instance variables are quite interesting.
Yes, that is a missing ingredient in most proposals we've seen.
And inquiring minds want to know more about them. I assume they're
scoped to the entire class body, right? And they hoist to the top?
Could they have initializers that were automatically included in the
constructor?
A comment in your gist (lines 186-187) seems to say that with 'private
x', we can use @x or this[x]. Is that really what you meant? Plain 'x'
is bound to the Name object and @x is the value of the property with
that name? Is x a variable? Does this mean that the class desugars into
something that has a let statement surrounding the all the methods?
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 ordinary unary @ would dominate and .@ would be relatively
rare. But when used, it would at least look like noisy property access
rather than an email address. My gut says that regularity of syntax
wins over conciseness and noise here.
And a question: do we really need both the private declaration and
the sigil?
Yes. Otherwise the private declaration takes over all dot references
of any such name, and that's wrong. We have no static types to
consult, so we have to use a different sigil/operator.
I'm not convinced that public and private properties ought to be in
different namespaces, though I can see that that would have some advantages.
Note @ in Ruby for instance-private ivars. You have to message an
"other" parameter to get its x and y (if it's a point) or have that
message send fail at runtime -- or check its type in your dyadic
method and double-dispatch, etc.
But more to the point, you've defined a syntax that allows us to drop
'this' from our methods! That's seriously cool.
Only for private vars.
So cool that I expect using private properties will become the
default and normal public properties will be the exception.
Unless... Can you also allow 'this' to be dropped for public
instance variables? With a 'public' declaration and/or a different sigil?
We could use the same sigil/namespace, but then public and private
names could collide and that seems future hostile. I may have API
growth where a common name I've used for a private is now required for
a public in order to interface to some third party code.
Because the private names are private, changing them would be easy to
do, at least...
Do you expect the performance of private property lookup to be
equivalent to public property lookup? That is will @foo take the same
time as this.foo? Because everyone is going to want to use @foo for its
convenience if there is not an equivalent trick for public properties.
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.
You're right. Plain dot doesn't work.
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.
For what its worth, I'd be willing to live with another sigil for the
convenience of not having to type 'this.' (But it still seems like it
ought to be possible to unify both public and private declared
properties with a single sigil, if you are willing to put them in the
same namespace.)
David
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
