Nov 16 meeting notes

Waldemar Horwat
Wed Nov 16 17:19:20 PST 2011
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018508.html
Here are my rough notes from today's meeting.

    Waldemar

IPR discussions

Test262 status

Internationalization: due by March meeting if we want to try for June GA


Doug Crockfords's presentation at Silicon Valley Code Camp.  User feedback
gathered by Doug:

* Users like quasis.

* Half of the users vehemently opposed large syntax changes (paren-free
etc.) that change syntax merely to add a different way of doing largely the
same thing.  They know that they don't have to use the new syntax, but they
also don't want to see it in code they read.

* Virtually all users hated block lambda.

* Users not looking forward to new class syntax but not as opposed.

* Users liked the ... operator.

* Users would like some functionality to gather stack traces to do things
like remote application diagnosis.

* Users generally liked modules.

* Confusion about map.  Particularly for people who work on (geographic)
maps.

* Requests for Object.flatten (collapse prototype chain into one object),
copy, and deep copy.

* Users support elective use of Unicode characters as alternate forms of
syntax tokens.  Examples: ≤, λ, etc.

* Some users wanted a NoSuchMethod trap on Object.prototype.


Allen's update on ES 6 Draft Specification

Allen: Wanted to allow an identifier named "arguments" only in the case
where it's the ... parameter:
function f(x, y, ... arguments) {...}
Objections: Unnecessarily complex.  This isn't the same as the deprecated
meaning of arguments because it doesn't include x and y (and also is an
array instead of an arguments object).
Consensus: Don't make a special exception for use of the identifier
"arguments" here.

function f(a, b = g()) {
  function g() {return a}
}
What happens here?
Waldemar, DaveH, and several others:  b's initializer doesn't see the
internal definition of g because the call to g is outside the braced
scope.  A forward reference here is counterintuitive.

Oliver: What about these?

var x = 1;
function f(a = x) {
  var x = 5;
}

function g() {return "g1"}
function f(a = g) {
  return a();
  function g() {return "g2"}
}

MarkM: Two-scope model (one scope for parameters, an independent inner
scope for let, const, and var bindings).  This model is upwards-compatible
with ES5.1 strict because the latter disallows shadowing of a parameter by
a binding in function scope.

Allen: Two-scope model, but with inner scope prohibited from shadowing
parameters.
MarkM: Likes this.  Any program that is accepted works with either of the
two-scope model intuitions.

Waldemar: What about this?

var d = 12;
function f(a, b = a, c = d, d = 0) {...}

Do we have let, let*, or letrec semantics for a, b, c, and d?

Consensus: letrec with temporal dead zone, so the above would be an error
when evaluating c's initializer because d hasn't been bound yet.

DaveH: Concerned about let temporal dead zone semantics (in general for
let).

Waldemar: Dead zone very unlikely to come up for parameters in practice.
The compiler can readily see if parameters are forward-referenced in uses.
Of course, it is possible to come up with obscure cases that demonstrate
the dead zone:

function f(a, b = function(){return d}, c = b(), d = 42) {...}


Waldemar:  Point of order.  Concerned about a number of items not approved
in May appearing on the ES Harmony agenda for this meeting (section 5 of
the meeting agenda).  While Waldemar likes some of them and is as eager as
anyone to discuss them, it would be better to separate them into a separate
heading such as section 6 to make it clear to us and anyone watching
whether the proposals are for ES.Next or for a future revision of
ECMAScript.  When posting agenda items, please indicate whether they're for
ES.Next or for future revisions.


Internationalization presentation.

Allen:  Can a web developer reasonably depend on his webapp working the
same in a given locale on any conforming browser?
Answer: No.
MarkM: Are there specific areas where it's possible to pin implementations
down more?

Alex:  Wants a way to globally set a default localeList based on
application-specific data.
Long debate.  Not possible as defined currently.  Have the Globalization
object default to getting a localeList from one of its user-settable
properties if not provided in a function call?
MarkM:  Doesn't want mutable globals (other than ones that are set up once
and then frozen).
Alex:  If you don't allow mutating the default, applications will still
store the locale in a global and just pass the value of the global to every
method that takes a locale, resulting in a more wordy program.
Waldemar:  Sometimes users will want to change their locale from within the
application.
Waldemar:  While having either a mutable default locale or having no
default locale would be ok, having a default immutable and
implementation-dependent locale would be a problem, as it would be hard to
usefully rely on such a thing.

Brendan: Looks like the identifier "Globalization" is used in existing JS
libraries.  Not sure in what capacity yet.

Timezone faithfulness across changes in the timezone laws issue.

Contains: Should the position parameter match IndexOf or lastIndexOf?

Array and string methods will continue to treat strings as pure sequences
of 16-bit values.

randomInt is based on Math.random.

Will add erf/erfc/gamma if they're in the common math libraries.


Map/Set:
Size property should be a getter property with no matching setter.  It's
defined on the property.
What is its name?  size, count, or length?  Decide on es-discuss.

Default for-of iteration on Sets is clear.  On Maps, should the default
iteration return the keys or key-value pairs?
for-in iteration on Maps and Sets doesn't do anything useful.
You can ask for the other kinds of iteration on a Map by running a method
(not a getter because it's not idempotent).

What is the order of enumeration?  Insertion order (and without any
exceptions for integral keys -- MarkM: who would define a language feature
like that ;-)?

Does creating an iterator snapshot the object?
Brendan: If enueration order is insertion order, a Map or Set would make a
useful worklist abstraction as long as new elements do appear in iteration.
Waldemar: What are the alternatives?  Snapshotting would be heavy-weight.
DaveH: The alternative is to throw from the iterator if the object has been
modified since the previous iterator call.
MarkM: Now in the worklist semantics camp, merely to avoid weird iterator
state.

Argument over whether Map.prototype is a Map.  We want to avoid the mess
caused by Date.prototype being a Date (MarkM: It provides a hidden
communication channel that cannot be frozen).
What happens when you extract Map.prototype methods and apply them to an
object that is not a Map?
Type error.
Allen: Wants the prototype to be an instance of the class for consistency.
Waldemar, MarkM, DaveH: The prototype is not an instance of the class.
Empirically, the only things that act as instances of user-defined classes
are the things that inherit from the prototype, not the prototype itself.
Will continue on es-discuss.  However, we agree that there should be no
mutable private state in the Map/Set constructors.

Also need to fix Date.prototype.  Its private state should be frozen as
well.

DaveH: Use === or egal?  Distinguishing ±0 as separate slots in a Map or
Set will confuse users.
MarkM: What about defineOwnProperty?  Same problem would appear there.

More information about the es-discuss mailing list