Here are my meeting notes for today. Waldemar
WebIDL: Can abstract interfaces have static members? Don't see why not -- they'd just be spec sugar for adding the same static member to concrete classes that derive from those abstract interfaces. As usual, it would be a spec error to have a collision. Debate over combination of overloaded methods from different base abstract interfaces. Issues come up with combining overloads of abstract types -- per yesterday, the structural "union" of two abstract interfaces A1 and A2 can contain instances that are in neither A1 nor A2. General feeling is to avoid the issues if feasible. Property enumeration order: Decided that this is a TC39/ECMAScript issue, not a WebIDL issue. Dealing with argument count mismatches: Ignoring additional arguments is useful for upwards compatibility (example: adding an extra dirty region argument to draw methods that would be ignored by older browsers that would just redraw the whole canvas). Overloading is a mismatch with future-proofing argument count mismatches. Proposal: treat each function call as having infinitely many trailing "undefined" arguments, and overload only on types, not argument count. Brendan on special operations: "don't want to see any more of these darken our door". Trouble is that these kinds of catch-alls allow most names but not all names, leading to brittle or exploitable code. It's better to provide get and set methods. However, Stringifiers are ok. Error objects have their string properties (name and message) defined on their prototypes in ES3. IDL errors can create instances with instance properties for name and message rather than delegating to a prototype, and everything ought to work. Browsers like to add other properties to Error objects they create. Not clear how to link into that functionality. Throw this back to TC39's core language discussions. Returned sequence types are returned as arrays. That means that they must be copies each time they're returned. Should they be frozen? Not much enthusiasm for that.... What about passing arrays into IDL? The IDL can just access whatever it wants because it has control until it returns. Except that it doesn't if there are getters, setters, or proxies in the data structure passed to IDL -- the order of accesses is discoverable, and the data structure can mutate itself as it's being read. The proposal of having IDL read data structure "as if copied" is not practical. Some methods might only want to access one element of an array and don't want to copy the whole thing. We won't require users to freeze arrays before passing them into IDL. That would be too cumbersome. We won't require IDL to freeze arrays before passing them to users. Every array will be fresh. Discussion about indexGetter and indexSetter. Separate path for looking up numerical indices? John, Brendan: Want to avoid high management overhead for cooperating with W3C. A lot of liaisoning formality or large meeting would be undesirable. Discussion about desirability of writing a style guide or joining TAG. Style guide may be ineffectual -- it's better to just have somone who understands style review proposals -- while TAG has no teeth to enforce its mission, so it's practically been ignored. --- Next meeting on Jan 18-20 at Yahoo. Ballot resolution meeting at 3pm on Jan 19. We'll send the final ISO draft to ISO tomorrow (Thursday) and also place the draft on the ECMA website. Allen: Need to re-designate the document as a draft if we let it out now. Consensus on removing the test results altogether from the test262.ecmascript.org web site. Having results there would provide too many incentives for trying to game the system rather than build a good test suite. Debate on whether do commit-before-review or review-before-commit on the test suite. Would be good to get rid of the powershell platform dependency when submitting tests. Discussion about whether we can get rid of -0. Some are in favor but no, we can't. We also can't make -0 !== +0. Either would be a large breaking change. Some desire to make the identity operation syntactically as attractive as ===. Could we make the identity operation into an infix operator named "eq"? Waldemar: Syntactically, we could, and we wouldn't even need to make "eq" into a reserved word. The production would have to be: expr1 [no line break here] eq expr2 The reason the [no line break here] has to be in the first gap instead of the second one is to maintain compatibility with the existing code that counts on semicolon insertion: a = x eq = y which would continue to parse as: a = x; eq = y; Agreed to move this into the proposal stage. const function joining: Vigorous debate. Some don't like specifying the optimization algorithm. What is its asymptotic complexity? Oliver would object if it's greater than n*log(n) but might object anyway. Waldemar: Opposed to mandating making dead code change semantics of live code, as in: const debug = false; const divisible(m) { return const(list) { return list.filter(const(n) { if (debug) log(list); // dead code return n%m === 0; }); }; } Now the innermost function has different === function instance behavior thanks to the dead code it contains. The behavior ought to be identical to: const divisible(m) { return const(list) { return list.filter(const(n) { return n%m === 0; }); }; } Debate over syntax. No particular resolution. Everyone seems to have a different view on this. A: Skeptical about syntax. B: Like it but would want to make joining implementation-defined. C: Don't think users will want to freeze functions much. D: Not convinced secure mashups have been demonstrated. E: Would like even shorter syntax. F: Figure out asymptotic complexity. G: Use λ as the syntax. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss