Sep 30 meeting notes

Waldemar Horwat
Thu Sep 30 17:43:02 PDT 2010
Here are my raw notes for today's meeting.


Excellent Japanese ISO comments!

Discussion of the comment on 7.9.1:

  break [no LineTerminator here] Identifier-opt ;


  break [no LineTerminator here] ;
  break [no LineTerminator here] Identifier ;

which then means that code like:


is rejected.  This is a bug in the ES5 spec.  In the prehistory of ES3
we had intended the following:

  break ;
  break [no LineTerminator here] Identifier ;

but we over-abbreviated.  Waldemar proposed fixing the spec to the
two-line form above for break and continue, and an analogous fix for
return.  Consensus to fix it if we can intercept the draft disposition
of comments document before it arrives at ISO.

Firefox conforms to the corrected grammar.  Safari does something
unusual:  It allows a line terminator after the break but considers a
semicolon after the line terminator to be an empty statement.  This
shows up if one writes:

if (...) break
; else ...

which is an error in Safari but not Firefox.  We hope Safari will fix
this tiny corner case.

If a ballot resolution meeting is needed, Waldemar will represent
TC39.  Allen can't do it because he can't have dual roles in this
process, also being the editor of the ISO standard.

Microsoft executed the ECMA contributor agreement.
Google hasn't yet but intends to.
Allen would like to publicize the site at some point as an official
place for ES tests.
Several of us want to make sure that, if it's publicized, this is
perceived as a work-in-progress, not as something that "certifies",
"validates", ensures "conformance", etc. of implementations.

MarkM: ES5 tests are currently too wimpy.  The pass rate is too high
for implementations we know not to be ES5-conformant.

Fear is that journalists will look at a "98.72% conformance" grand
total score and use it as a figure of merit.  There will be pressure
for vendors not to put up new conformance tests that they themselves

MarkM and Waldemar: Please delete the grand total score line.

John Neumann: Concern about naming vendors in test results (as opposed
to anonymous "Vendor 1", "Vendor 2", ...) on an ECMA-related site.

Internationalization effort:

Google and Microsoft are interested in participating.  Maybe Mozilla.

Should the internationalization library standard be in lockstep with
ES-Harmony, targeted for 2013?  No need to wait for Harmony.
Allen thinks that 2012 is realistic for a separate
internationalization library standard.
Waldemar: We can decide later whether it's best to fold the
internationalization library into Harmony or leave it separate.  If
it's separate, we'll need to face issues with Harmony security,
multiple global objects, etc. that may need to be backported to the
internationalization library.

First internationalization meeting in November.  We'll share the
es-discuss mailing list.

Next meeting: Nov 16 (internationalization), 17, 18

MarkM and Sam Ruby:  Interested in standardizing a debugging API.
There is already some prior work, such as IBM's JSDT.

A number of others are interested in following the effort on es-discuss.

Classes as sugar:

Should public fields be enumerable?  Yes, so the object can be
serialized via JSON.  Also, when traditionally creating objects as
records, the fields will be enumerable.

Waldemar:  Traits and classes-as-sugar proposals seem remarkably similar.
Waldemar:  How does one do class-private in the current traits
proposal?  MarkM:  You can't.
Waldemar:  Concerned about easily being able to define high-integrity
abstractions using whatever we use for classes or traits.  Don't want
to be able to sneak in something that looks like a ComplexNumber to
some consumer but then spontaneously changes value after being

We'll need to work out the corner cases of "this" usage in both
proposals.  We'll also need to address what happens when we throw out
of a class block but squirreled away the value of "this" in a global
variable.  Probably no big deal.

Having the syntactic form "public foo = ..." to create a publicly
readable, privately writable field is confusing.

Open discussion about interaction between traits and prototype chain.
Traits follow prototype chain when used with Object.create; they are
prebound when used with Trait.create.  Debate about whether the common
case is promiscuous object, nonpromiscuous objects, or both.

Dave: Somewhat prefer the Object.create approach.

MarkM: Make it convenient to create defensible objects.

Making traits high-integrity is inconvenient:

trait class PointTrait(x, y) {
  function getX() {return x;}
  => {
    getX: getX,
    ... getX ...  // High-integrity usage
    ... this.getX ...  // User overridable usage

There's no way to do the high-integrity usage on another (non-this)
instance of a trait.

Schism within group about goals: "high integrity" vs. "supporting the
things that people are already writing with better syntax" vs. maybe
possible to get both

MarkM: In the world of mashups, new compositions come up on users'
computers that developers did not test ahead of time.  Need to ensure
that components are robust/reliable enough individually so that the
compositions will just work without the need for testing.

PostMessage security alternative: Very hard to program due to
asynchrony at all inter-module boundaries.

Object initializer syntax:
Angle brackets useful for disambiguating things like:
var arrayLike = [
  <prototype: obj>,
Per wiki, this is has [[class]] Object, not Array.  Debate about
whether it should be Array or whether we should allow <class: expr>.

Grammar is ambiguous because it allows the > operator in the
expression inside <prototype: expr>.

Wiki proposal doesn't allow null prototypes.  Agreed to allow them.

Debate about whether the closing > should be followed by a comma.

What is the "final" metaproperty?  It's "nonextensible" with a
confusing name.  Groans -- fools people into thinking that the object
can't be used as a prototype.

Objections to making "const" fields automatically nonenumerable.  This
tying of two independent concepts makes it hard to serialize via JSON,

Private properties are controversial.  Do they pertain to just the
instance being constructed, or can they be applied to foreign

Waldemar, MarkM:  If sole-instance, they're better expressed via
closures (with an argument about implementation speed).  If they're
not sole-instance then within the context of "private privateVar", the
expression "a.privateVar = 3" will do something different from
a["privateVar"].  Instead, it will create a hidden property on a and
give it the value3.

Allen's "static" proposal: Algol 60's "own" variables.
At what point does a static initializer get evaluated?  Function
expression: at the time that the function itself is created.  Function
declaration: we'll have to think about it.

Waldemar: Not clear there is a right answer to when a static
initializer gets evaluated for a function declaration.  The obvious
choices are either at the beginning of the next-outer function or just
before the inner function declaration would have been executed.  Each
choice is wrong for one of the statics s1 or s2 below:

function Outer(x) {
  // Initialize s1 and s2 here?
  let y = ... x ...;

  // Initialize s1 here?
  function Inner1(z) {
    static s1 = y;
    ... s1 ...

  // Initialize s2 here?
  function Inner2(z) {
    static s2 = x;
    ... s2 ...

Of course, we should also support "static static static" to go up
three function levels.

More information about the es-discuss mailing list