Minimalist Classes

David Flanagan dflanagan at mozilla.com
Wed Nov 2 10:52:29 PDT 2011


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 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 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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


More information about the es-discuss mailing list