My rough notes for today's meeting.<br><br>    Waldemar<br><br><a href="http://Test262.ecmascript.org">Test262.ecmascript.org</a> presentation<br>Allen: There will be substantial changes to section numbering in ES6.  Concerned about too much dependence on section numbers in Test262.  However, there exist tools to rename Test262 files with new section numbers.<br>
<br>Debate sparked by test262's requirement that defineProperty throw if it can't create the property -- that's an invariant that even host objects are not allowed to violate.  We can't test all possible property names and objects, so the authors of the test have chosen ones which some implementations are known to violate.  Is this kosher?<br>
Yes -- this is a normative invariant in the spec, even for implementation extensions.<br>Discussion over refactoring of such tests to parametrize them over the property names known to violate the spec.  This way the tests can include different implementations' suspicious properties.<br>
Debate over whether errors the test finds should be labeled as DOM errors or ECMAScript errors.<br><br>Test262 Technical Report will be submitted to the December GA.  It must be approved and sent to ECMA members by October 8th to make it to the December GA.<br>
<br>Discussion about updating the ECMA TC39 web page.<br><br>ParallelArray demo.<br>Currently the implementation is very hacky (i.e. works mainly just for this demo), but shows great promise.<br>Discussion:  How do we express arithmetic on number types other than IEEE double?  This is a different problem from typed arrays in that we want to actually compute using other types (int8, float32, etc.) rather than just store using those types and convert to doubles for computation.<br>
<br>Allen's presentation on current state of the spec.<br>Question: We have an opportunity to make function declarations create immutable bindings if they occur inside blocks.<br>Answer: Consensus on making them consistent with function declarations outside blocks.  Either we'd make all function bindings mutable or all immutable.<br>
<br>Discussion about object literal attribute modifiers.  Objections to using := for immutable properties (intuition is opposite from that of Pascal).  Disagreement over whether immutable properties should be nonenumerable -- some are the same in every instance, some are immutable but have different values in different instances.<br>
No consensus on any concise way of marking properties nonenumerable.<br>DaveH: Prefer to play it conservative and do nothing rather than introduce a funky new syntax.<br><br>Evaluated property names:<br>{<br>  [foo]:1,<br>
  get[1+2](){},<br>  ['prefix'+i++](){}<br>}<br>Waldemar: Concerned that these look too much like array literals or an array index expression on an array named "get", which is not a reserved word.<br>These can produce property name collisions at run time.  What should happen?<br>
A. Rely on DefineProperty semantics, which sometimes allow rebinding of properties<br>B. Throw<br>In choice A we'd then have to allow collisions in literal property names as well.  Leaning towards choice B.<br><br>Method form is not a constructor.  Why?  To be consistent with built-ins.  Hotly debated whether we should be consistent here (and consistent with what -- with built-ins, with bind, or with standalone functions?) and whether the extra constructors are useful.<br>
<br>super wiring: If 'super' is nested inside one or more functions inside an object literal, what does 'super' bind to?<br>{<br>  f:(0, function(){... super ...}),<br>  g:function(){... super ...},<br>  h(){... super ...},<br>
  k:... super ...<br>}<br>Another hot debate with no convergence.<br>If it doesn't bind to anything, should super:<br>A. Be a compile-time syntax error?<br>B. Return null?<br>C. Return an empty object?<br>D. Throw an error when containing function is entered?<br>
E. Throw an error when evaluated?<br>Not resolved.  Allen's proposal currently has choice C if super is used in a property lookup and the value of 'this' if super is not used in a property lookup.<br>Debate over the meaning of:<br>
function returnUndefined() {<br>  return super.foo;<br>}<br>What about<br>function returnUndefined() {<br>  super.foo = 42;<br>}<br>Error because there is no object.<br><br>What about assignments to super.foo in general, when there is a super?<br>
Allen: These behave the same as assignments to this.foo<br>Waldemar: These should either do the 'super' thing or be an error.  Silently changing the meaning to not do 'super' lookup is gratuitously unsymmetric.<br>
<br>Commas optional after method/getter/setter definitions.  These currently always end with }.  Note that an equivalent member definition that initializes the member to a function does not make the comma optional (and can't because of things like:<br>
{<br>  g:function(){...}<br>  [expr] ...<br>}<br>where the [expr] is an array lookup on the function literal.<br><br>Debate over whether method properties should be writable and configurable or not.<br>Brendan: Use # to mark nonwritable/nonconfigurable properties.<br>
Waldemar: Want to have easy ways to specify both writable and non-writable nonconfigurable properties.<br>MarkM: Nonconfigurable writable properties don't make sense because an adversary can freeze them.<br>Waldemar: That's a design bug we have to live with, but they're still useful in the common case.<br>
Brendan: Accessors might solve this.<br>Waldemar: Accessors are too wordy and would also rely on private properties here.<br>Alex: Common accessor pattern of intercepting writes but passing reads through is too wordy and could use better support.<br>
<br>Waldemar: For methods, use # to mean nonconfigurable/nonwritable.<br>For value properties, use # to mean nonconfigurable/writable.<br>For value properties, use const to mean nonconfigurable/nonwritable.<br>None of these prefixes have any effect on enumerability.<br>
<br>Alternate proposal: use # in front of entire object to freeze (MarkM) or seal (Waldemar) object.<br><br>Reached consensus on the following # proposal:<br># before an object literal seals the object<br># before a propoerty makes that property nonconfigurable and nonwritable.<br>
All method properties are nonenumerable.<br>All value properties are enumerable.<br><br>{x} desugars into {x:x} in the proposal.<br>DaveH: Would prefer to turn that into {x:void 0};<br>DaveH withdrew proposal, but now Waldemar wants to do that, in order to be able to define objects that contain uninitialized instance variables x, y, z, length:<br>
#{x, y, z, length, ...}<br>without capturing the values of x, y, z, length from the outer environment.<br><br>Allen's "class" definition pattern:<br>DaveH: Too imperative for what should be a declarative construct<br>
Brendan: Doesn't substitute for classes<br>MarkM: How would you freeze everything?<br>Getting the .prototype. and .constructor. sections out of order or omitting one would lead to weird errors.<br><br>DaveH:<br>Dislike the use of .{ for object extension.  Like the idea in principle.  It's not enough to say "this is the semantics we want, pending finding the right syntax".<br>
Some like the syntax.  Debate.<br>About as many syntax variants offered as there are people in the room.<br><br>