Nov 17 meeting notes

Waldemar Horwat
Wed Nov 17 17:23:21 PST 2010
https://mail.mozilla.org/pipermail/es-discuss/2010-November/012183.html
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.

More information about the es-discuss mailing list