Here are my raw notes from today's meeting. Waldemar
Proxies: Discussing open issues on http://wiki.ecmascript.org/doku.php?id=harmony:proxies 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 standing:) Allen: Some validation is expensive (looking for duplicate names in getOwnPropertyNames). 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 proposal. 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 (isprime(y))] 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: Refactor foo(bigexpression for (y in z)) into: let i = bigexpression for (y in z) foo(i) which unfortunately would be transformed by semicolon insertion into something quite different: let i = bigexpression; for (y in z) foo(i) 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 aLocale.prototype.foo should be Locale.foo; some should be Locale.prototype.foo. 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 pattern? 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(col.compare) 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 getPropertyNames. Agreed to retain only getPropertyDescriptor and getPropertyNames. Next meeting (at Mozilla) moved to Sep 30/Oct 1. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
