Sep 27 meeting notes

[Brendan Eich]

On Sep 30, 2011, at 7:57 PM, Erik Arvidsson wrote:

> One of the things I like about the object literal syntax is that it
> doesn't seem like things might be in scope. Take this example (with
> intentional error):
> 
> class Point {
>  var x = 0;
>  var y = 0;
>  distance(other) {
>    return Math.sqrt(x * other.x + y * other.y);
>  }
> }
> 
> it is very tempting to think that var x and var y are in scope. If an
> object literal is used at least we have the current behavior to steer
> people into doing the right thing.

Two thoughts:

1. Oliver and others do want x and y to be in scope somehow. They can't be via the |this| parameter object on the scope chain, though. That's dynamic scope (the prototype is extensible, or *a* prototype, possibly Object.prototype, is). But the desire to avoid this. prefixing is natural and predictable for people coming from C++, Java, etc. Should we consider supporting this expectation somehow, rather than steering people away from it with less natural syntax?

2. The variant Bob and I were hacking on just now allows class data properties to be declared using const or var (shall we say, let). This still can lead to the expectation that class property  names are in scope for class methods, or even all methods. Bob's constructor set class.lastPoint = this; but for some folks (Java heads), it would be more natural to set lastPoint = this. I'm not defending, just noting the declaration implies name is in scope problem you cite applies to class: properties in the variant proposal.

If we wanted to support x and y bindings in methods as lexical aliases to this.x and this.y, given declarations, could we do it? Doing this would hide any outer x and y. Same question goes for lastPoint, although it seems to me we are free to shun the Java influence by not aliasing unqualified lastPoint to Point.lastPoint in prototype methods. We could alias class property names in class methods too.

What does it mean to alias properties with lexical bindings? The referent properties' object must outlive the lexical scope. That's easy with |this| in method activations, and I think also can be arranged for the class within a class method.

Another implication is that the referent properties are non-configurable. That leaves writable: true, which creates an alias analysis problem. Any property reference in a method, say foo.x, could alias the storage referenced by lexical x, to wit: this.x. So reads and writes would have be coherent, a challenge to optimizing JIT-based VMs. Not a huge problem for implementors, but could this make for confusion among users because x = 42 updates this.x?

See http://wiki.ecmascript.org/doku.php?id=discussion:block_expressions#let_ref_as_a_reformed_with where Lars Hansen mused about Modula 3's WITH statement, which does alias fresh lexical names to variables including writable variables.

Adding lexical aliases to certain properties does add new semantics. Dave reminded us (me anyway) at last week's TC39 meeting that we do not rule out new semantics if warranted, we simply prefer desugaring to existing kernel semantics where that works, and we try hard to avoid additions.

My question for everyone: will users expect declared property names to be in-scope, no matter what the syntax for declaring or defining them is? I suspect so, and that makes me think we're not going to do well by "counter-steering" with object literal property init syntax.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110930/0b0b1474/attachment.html>