Sep 26 meeting notes

[Waldemar Horwat]

My rough notes for today's meeting.

    Waldemar

Test262.ecmascript.org presentation
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.

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?
Yes -- this is a normative invariant in the spec, even for implementation
extensions.
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.
Debate over whether errors the test finds should be labeled as DOM errors or
ECMAScript errors.

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.

Discussion about updating the ECMA TC39 web page.

ParallelArray demo.
Currently the implementation is very hacky (i.e. works mainly just for this
demo), but shows great promise.
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.

Allen's presentation on current state of the spec.
Question: We have an opportunity to make function declarations create
immutable bindings if they occur inside blocks.
Answer: Consensus on making them consistent with function declarations
outside blocks.  Either we'd make all function bindings mutable or all
immutable.

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.
No consensus on any concise way of marking properties nonenumerable.
DaveH: Prefer to play it conservative and do nothing rather than introduce a
funky new syntax.

Evaluated property names:
{
  [foo]:1,
  get[1+2](){},
  ['prefix'+i++](){}
}
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.
These can produce property name collisions at run time.  What should happen?
A. Rely on DefineProperty semantics, which sometimes allow rebinding of
properties
B. Throw
In choice A we'd then have to allow collisions in literal property names as
well.  Leaning towards choice B.

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.

super wiring: If 'super' is nested inside one or more functions inside an
object literal, what does 'super' bind to?
{
  f:(0, function(){... super ...}),
  g:function(){... super ...},
  h(){... super ...},
  k:... super ...
}
Another hot debate with no convergence.
If it doesn't bind to anything, should super:
A. Be a compile-time syntax error?
B. Return null?
C. Return an empty object?
D. Throw an error when containing function is entered?
E. Throw an error when evaluated?
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.
Debate over the meaning of:
function returnUndefined() {
  return super.foo;
}
What about
function returnUndefined() {
  super.foo = 42;
}
Error because there is no object.

What about assignments to super.foo in general, when there is a super?
Allen: These behave the same as assignments to this.foo
Waldemar: These should either do the 'super' thing or be an error.  Silently
changing the meaning to not do 'super' lookup is gratuitously unsymmetric.

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:
{
  g:function(){...}
  [expr] ...
}
where the [expr] is an array lookup on the function literal.

Debate over whether method properties should be writable and configurable or
not.
Brendan: Use # to mark nonwritable/nonconfigurable properties.
Waldemar: Want to have easy ways to specify both writable and non-writable
nonconfigurable properties.
MarkM: Nonconfigurable writable properties don't make sense because an
adversary can freeze them.
Waldemar: That's a design bug we have to live with, but they're still useful
in the common case.
Brendan: Accessors might solve this.
Waldemar: Accessors are too wordy and would also rely on private properties
here.
Alex: Common accessor pattern of intercepting writes but passing reads
through is too wordy and could use better support.

Waldemar: For methods, use # to mean nonconfigurable/nonwritable.
For value properties, use # to mean nonconfigurable/writable.
For value properties, use const to mean nonconfigurable/nonwritable.
None of these prefixes have any effect on enumerability.

Alternate proposal: use # in front of entire object to freeze (MarkM) or
seal (Waldemar) object.

Reached consensus on the following # proposal:
# before an object literal seals the object
# before a propoerty makes that property nonconfigurable and nonwritable.
All method properties are nonenumerable.
All value properties are enumerable.

{x} desugars into {x:x} in the proposal.
DaveH: Would prefer to turn that into {x:void 0};
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:
#{x, y, z, length, ...}
without capturing the values of x, y, z, length from the outer environment.

Allen's "class" definition pattern:
DaveH: Too imperative for what should be a declarative construct
Brendan: Doesn't substitute for classes
MarkM: How would you freeze everything?
Getting the .prototype. and .constructor. sections out of order or omitting
one would lead to weird errors.

DaveH:
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".
Some like the syntax.  Debate.
About as many syntax variants offered as there are people in the room.