Day 2 meeting notes

Waldemar Horwat
Thu Jul 29 14:47:18 PDT 2010
Here are my raw notes from today's meeting.


Proxies: Discussing open issues on
How much validation to do?  Do we do as much as we can stand?
(Brendan, Allen, Mark: Depends on who it is that is doing the
Allen:  Some validation is expensive (looking for duplicate names in
Copying and normalizing results (property descriptors etc.) also has cost.

Allen:  A script could override Object.getOwnPropertyDescriptor and
cause trouble.
MarkM: That's why for secure frames you'd have an initializer script
that freezes things like Object.getOwnPropertyDescriptor.
Allen:  If you do that, the initializer script could substitute
Object.getOwnPropertyDescriptor with its own, more bulletproof
version.  This puts the burden of validation on those who want it.

Debate about whether having tight restricitions now and relaxing them
later could be called "upwards compatible".
Waldemar: It's a stretch to put that label on it, just like I wouldn't
call a change of functionality of a safe from having only the right
combination open it to having anyone be able to open it an "upwards
compatible" change.

Debate about the expense of copying/normalizing for validation.

Comprehensions:  To be useful, need to have a bunch of basic helpers
such as range(), properties(), values(), etc. with short names that
can be used to construct comprehensions.  These will be added to the

Would like to be able to interleave for and if clauses:
[x*y for (x in range(...)) if (isprime(x)) for (y in range(x+1...)) if
This is allowed by the proposal but not by the wiki.
The proposal has the grammar (for let? if?)+.  This doesn't currently
allow let-if-let-if combinations, where the second let is valid only
if the first if returns true.  Would be nice to allow orders like
these too.
Debate about array comprehensions without a for clause:
for (x ...) {
  ... [x if (isprime(x))] ...
This would generate either a 0- or a 1-element array depending on the
if condition.  Duly noted.

Generator comprehensions:  (foo for (key in obj))
Desugars to functions, not lambdas!
(function() {
  for (let key in obj) {
    yield foo;
Controversy for what happens if the generator expressions contain:
- arguments  (make it work?)
- this  (make it work?)
- yield  (outlaw it?)
- var, break, return inside a let expression  (don't bring back let expressions)
Require parentheses around a generator comprehension even if it's used
as a function argument?
Python does.
Here's one thing that could happen if we don't require parentheses in
some contexts:
    for (y in z))
let i = bigexpression
        for (y in z)
which unfortunately would be transformed by semicolon insertion into
something quite different:
let i = bigexpression;
for (y in z)

const functions:
Waldemar: Grammatical and readability concerns about confusion between
const x and const x().  "const" alone restricts syntactic options for
destructuring.  Other options:  "const function", "def", ...
Erik: Common case is not to freeze everything.  Freezing won't work
with jquery listen functions etc.
Brendan: Makes it harder to rely on expandos.
Mark: Weak maps will solve the problem that expandos are used for now.
Waldemar: That would just bifurcate the problem, since browsers
without weak maps will be around for a while.
Brendan: Weak maps won't make Firefox 4.
Brendan: Education would be good but will take a while.
Allen: Not willing to commit to this as a proposal yet because of
concerns about its weight in making the language large.
Waldemar: OK with this feature, not with using just "const" as the syntax.
Doug: OK with this feature.

Internationalization API:
Prototype mistakes in the spec.  Some should be; some should be
MarkM: removeExtensions sounds too imperative (it actually returns a
new copy).  Rename it.
Waldemar: Don't understand the spec.  What is the pattern in
parseDate("29. jul 1974.", {"pattern": "yy-MM-dd"}, locale);
doing?  The supplied order is the opposite of the pattern and there
are no dashes in the supplied string.  Other pattern examples are
"yy/MM" and "yMMM".  Since the separators don't necessarily appear in
the matched string, what does the choice of "-" vs. "/" mean in the

Should this be developed by TC39 as a separate library standard?

MarkmM, Allen, Waldemar: Confusing which locale is which in
aLocale.prototype.getDisplayLanguage(locale).  The wiki documentation
contradicts the verbal explanation.  Also, the name should be
something something different like displayLanguageOf.

Explanation of difference between patterns and skeletons.  They use
different syntaxes and purposes.  Skeletons don't have delimiters or
punctuation.  A skeleton turns into a locale-appropriate pattern; if
the skeleton order would seem weird in the locale, the locale can
overrule the skeleton and produce a more appropriate pattern.

No current support for alternate calendards (i.e. Japanese calendar).

Setting collator strength should give a new collator instead of
modifying in place.  An even better solution would be a settings
object instead of a single strength parameter.

someStringArray.sort( doesn't work because compare is
defined on Collator.prototype.  You'd get the generic method not bound
to col.

Collators will canonicalize unicode characters (i.e. precomposed ö ==
decomposed ö).
Any single collator will always induce a valid total order.  The size
of the equivalence classes will vary.  For example, depending on
strength, it may consider u == ü.

Discussed merits of non-BMP unicode escapes using the syntax
\u{xxxxxx}.  Generally liked, but we can't use it in character ranges
in regular expressions without doing major surgery on regular
expressions.  Noncontroversial in other contexts.

String.direction questions:  There are more than just the two possible
directions.  Vertical?  A string containing parts with different
directions?  Indeterminate (example: empty string)?

Extended object API:
getPropertyDescriptor is useful for encapsulating property lookup on prototypes.

Allen, Waldemar: Concern about getPropertyDescriptors,
getOwnPropertyDescriptors, getPropertyNames being too eager and thus
asymptotically slow on objects representing large collections.  Would
want to be able to work with huge or infinite objects.

What would call the getPropertyNames trap?  Only another call to

Agreed to retain only getPropertyDescriptor and getPropertyNames.

Next meeting (at Mozilla) moved to Sep 30/Oct 1.

More information about the es-discuss mailing list