Here are my raw notes for today's meeting. Waldemar
Excellent Japanese ISO comments! Discussion of the comment on 7.9.1: BreakStatement: break [no LineTerminator here] Identifier-opt ; means: BreakStatement: break [no LineTerminator here] ; break [no LineTerminator here] Identifier ; which then means that code like: break ; is rejected. This is a bug in the ES5 spec. In the prehistory of ES3 we had intended the following: BreakStatement: 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. Test262: 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 fail. 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 validated. 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>, "element0", "element1" ]; 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, etc. Private properties are controversial. Do they pertain to just the instance being constructed, or can they be applied to foreign instances? 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? Inner2(); 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. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss