in: San Francisco - Mozilla
on: 27 - 29 Jan. 2015
TIME: 10:00 till 17:00 PST on 27th and 28th of Jan. 2015
10:00 till 16:00 PST on 29th of Jan. 2015
LOCATION:
Mozilla Foundation
2 Harrison Street
San Francisco, CA 94105
USA
CONTACT:
Allen Wirfs-Brock <[email protected]>
Attendees: please RSVP by the end of January 16th at this link: http://doodle.com/8yqkhbr25aapctck
Registration Link (TODO)
Please register before 20th of January 2015.
- Opening, welcome and roll call 1. Opening of the meeting (Mr. Neumann) 1. Introduction of attendees 1. Host facilities, local logistics
- Adoption of the agenda (2015/003)
- Approval of the minutes from Nov 2014 (2014/059)
- ECMA-262 6th Edition
- ES6 End-game schedule review (Allen)
- Final RF Patent Opt-out Periods for ECMA-262-6 and ECMA-402-2(Allen)
- ES6 draft status report (Allen)
- Recap of changes in recent drafts
- Review significant unresolved bugs and issues
- Subclass instantiation reformation: status and open issues (Allen)
- (see doc TC39 2015/005 on Ecma file server for miniutes of Jan 7 conference call)
- https://github.com/tc39/ecma262/blob/master/workingdocs/ES6-super-construct%3Dproposal.md
new.target
: in or out as user level feature for ES6?@@toStringTag
(rationales) (Jordan Harband) (es-discuss thread)- Should non-builtins be able to pretend to be builtins?
- If yes?
- Shims and faithfully built imitations can follow builtin code paths.
- https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.prototype.tostring step 17.b. can be deleted.
- If no?
- Missing unspoofable builtin values (
Math
,JSON
,Object
,Null
,Undefined
): spec bug - Should
Object.prototype.toString
add a prefix to all non-built-in@@toStringTag
values rather than a whitelist?
- Missing unspoofable builtin values (
- Should builtins be modifiable to pretend to be something else?
- No?
- Should built-in
@@toStringTag
values have{ configurable: false }
? - Does that cover just
*.prototype[@@toStringTag]
, or also own nonwritable nonconfigurable properties on every builtin instance? - Should that apply to only ES5 builtins, or to every builtin?
- Should built-in
- No?
- If yes?
- Proposed: class method syntax induces a non-enumerable method property, in contrast to method shorthand syntax in object literals and in concert with built-ins in the core language. (Brendan, et al.)
- Const in sloppy mode (Brian)
- Module loader spec integration (Dave)
- ES6 Introduction Text (Allen)
- ECMA-402 2nd Edition 1. Status Update (Rick)
- ECMA-262 7th Edition and beyond
- Reflect.isCallable and isConstructor (Jason Orendorff)
- Experimental new directions for JavaScript at Google (Andreas Rossberg)
- Move Decorators to Stage 0 (possibly Stage 1) (Yehuda Katz)
- Updates to Object.observe (Erik Arvidsson)
- Test 262 Status
- Report from the Ecma Secretariat
- Date and place of the next meeting(s) 1. March 24-26, 2015 (Paris - Inria) 1. May 27 - 29, 2015 (San Francisco - Yahoo) 1. July, 28 - 30, 2015 (Redmond, WA - Microsoft) 1. September 22 - 24, 2015 (Potland, OR - jQuery) 1. November 17 - 19, 2015 (San Jose - Paypal)
- Group Work Sessions
- Closure