TG1 San Francisco Meeting, 8-9 November 2007

• Douglas Crockford, Yahoo!
• Michael Daumling, Adobe
• Jeff Dyer, Adobe
• Brendan Eich, Mozilla
• Cormac Flanagan, UCSC
• Geoff Garen, Apple
• Lars T Hansen, Adobe
• Graydon Hoare, Mozilla (phone)
• Dave Herman, Northeastern University
• Waldemar Horwat, Google
• Dave McAllister, Adobe
• John Neumann, Toshiba
• Pascal-Louis Perez, Google
• Chris Pine, Opera
• Tom Reilly, Adobe
• Alex Russell, Dojo
• Scott Wiltamuth, Microsoft
• Allen Wirfs-Brock, Microsoft

• Opening
  • Introductions
  • Host facilities
  • Dinner arrangements
  • Lunch (Cafe Royale @ Adobe)
• Adoption of the agenda
• Approval of the October 30th minutes
• Openness policies of Ecma and TG1
• TG1 charter discussion
• Project editor’s report
• Open issues on which there is probably not much disagreement
  • #166: Namespaced constructor functions
  • #167: When are redefinitions allowed?
  • #172: A Function constructor that can deal with type annotations
  • #196: Does Vector need to be final, or have some final methods? (Depends on #214)
  • #214: Details surrounding catch-all methods
  • #219: Must a record type match the object it is annotating exactly?
  • #226: How does “eval” handle versions?
  • #234: The nature of byte / the new ByteVector (Depends on #196)
  • #247: Scoping of type declarations
  • #274/#275: parseInt, parseFloat, and Number.parse
  • #276: Specific rules of this propagation
  • #282: Removing restrictions on “use” and “import”
  • #283: Removing aliasing “import” from the language
• Open issues that may involve significant discussion
  • #112: The semantics of const
  • #212: Remove JSON
  • #258: How does “like” play with convertible types?
• Technical topics
  • Microsoft position on ES4
• Date and place of next meeting
• Adjournment

(These are the public minutes. The private minutes will be posted to the TG1 area on the members-only part of the Ecma web site.)

* Open issues

• #112 (”const”)
  • ⇒ some progress recorded in the ticket
• #212 (”JSON”)
  • LH: Summary of current recommendations
    • remove current JSON proposal
    • remove JSON altogether, or adopt json2 if this is not acceptable
  • DC: Current “json2” proposal on json.org is pretty fresh still, could wait
  • ⇒ we remove current JSON proposal
  • ⇒ we leave a JSON placeholder for consideration before ES4 is finalized
• #258 (”like” and convertibility)
  • ⇒ Convertibility is never deep.
  • ⇒ LH creates ticket if necessary on depth of “like”
• #166 (guarding against injection attacks)
  • ⇒ Solution (3) to avoid injection attacks.
• #167 (redefinitions)
  • ⇒ function and var are rebindable in some contexts, none other forms
  • Debate about whether type annotations should be allowed on redundant definitions, provided the annotations are all equivalent
  • Debate about equivalence (spelling vs meaning)
  • ⇒ Agreement that it’s ok with redundant definitions provided they have the same type
  • ⇒ Normalized types (mean the same thing)
  • ⇒ Some open technical issues about type normalization
• #172 (Function error)
  • ⇒ General agreement that we want to extend the Function constructor
  • ⇒ First n-1 are concatenated with commas
  • ⇒ If it starts with leftparen – no leading spaces! – then a return type may follow the rightparen
  • ⇒ No further rules
• #214 (catchalls)
  • ⇒ People believe it
  • ⇒ LH to open separate ticket on possible information leakage, see comment in ticket
• #196 (Vector finality)
  • WH: Not happy about Vector not being final, and if it isn’t, about its methods being overridable.
  • BE: Philosophical difference; JS is permissive by default
  • AR: Always possible to make the subclass final, non-dynamic
  • WH: Terrible things will happen.
  • ⇒ We keep it non-final, dynamic.
• #234 (ByteVector)
  • LH: Getting rid of byte is Good
  • LH: We could also go back to ByteArray
  • CF: Or we could have a separate ByteVector type with similar methods
  • ⇒ We’re not doing anything with this right now because there are several options available
• #219 (Record types)
  • WH: Permissiveness does nothing for typo detection
  • LH: Stronger cases for (1) and (2) being errors than (3)
  • ⇒ We’re making cases (1) and (2) errors.
• #226 (eval versioning)
  • ⇒ Deferred until the next meeting