Re: 4 June 2014 TC39 Meeting Notes
Le 11/06/2014 18:08, Ben Newman a écrit :
https://gist.github.com/annevk/3db3fbda2b95e5ae9427
AWB: Should we try to replace WebIDL? (fourth bullet point from the
gist above)
For what purpose? Replacing WebIDL isn't an end in itself.
Who would be the target of this replacement? Spec writers (TC39 or
W3C)? authors? Implementors? All of these together?
DH: Browser implementors love WebIDL, so anything that replaces it has
to be as convenient as that. YK's idea: the new interface description
language would prepend Legacy to existing WebIDL types, but still
support them
+1.
MM: What about a design language that compiles to WebIDL?
DH: Problem: people explicitly argue against better interface design
because it's not convenient/expressible in WebIDL.
MM: Right, the path of least resistance in WebIDL is not good JavaScript.
Why? (I'm not saying I disagree, but I'm trying to understand what
WebIDL lacks)
What are people opinions on the path of least resistance in describing
interfaces in TypeScript?
DH, AR: TypeScript seemed like a way to define signatures of APIs, but
was solving a different problem.
DH: Need a way to express what kind of implicit conversions are
applied to passed-in values (something that TypeScript doesn't have).
As far as developers are concerned, it doesn't seem like an issue, so it
looks like the TypeScript interface language is sufficiently expressive
for most developer needs.
However, it looks like the notion of interface for standard features
changes whether it's taken from the point of view of an implementor or
an author.
Implementors have an imperative of interoperability with legacy APIs
which is a constraint authors don't have.
YK: Also want to be able to express APIs in terms of function/method
overloading (different behaviors for different input types), which is
more like TypeScript than WebIDL.
AWB: If no work happens to build a better IDL, we'll be stuck with the
status quo.
YK: Want to be able to describe `PromiseT` result types as such,
rather than `{ then: ???, catch: ??? }`
I want to agree, but IIRC thenables are considered like promises by
built-in algorithms, so apparently, the consensus is not that people
want a `PromiseT` type as such separate from {then, catch?}.
SK: Willing to start working on a new IDL design, with help.
DH: Want to capture duality between Array.isArray arrays and
array-like objects, and instanceof-Promise objects vs. { then:
Function } objects.
SK: Can we improve whatever was lacking about TypeScript?
An annotation system like there is now in WebIDL might be enough an
addition to express legacy behaviors.
AR, YK: TypeScript types don't mean quite what you think they mean
(Number, String).
A new interface language could keep the TypeScript syntax and adapt the
semantics as felt appropriate.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 4 June 2014 TC39 Meeting Notes
On 6/12/14, 4:53 AM, David Bruant wrote: DH: Problem: people explicitly argue against better interface design because it's not convenient/expressible in WebIDL. To the extent that it's the latter, we should fix WebIDL. To the extent that it's people just being lazy, that's just not acceptable. Obviously we should try to make the path of least resistance be good interface design; WebIDL aimed at that from the start. It doesn't help that the concept of good interface design is not universally agreed on and not time-invariant So with that in mind, we want something that will allow us to express existing DOM APIs (which are by and large not good interface design in various ways), something that allows us to express whatever people actually want to express (and we better come to some agreement about what that is), and a way to transition from the current WebIDL to the new thing with minimal pain in some way, both in terms of rewriting all the existing specs that use WebIDL and browser implementations that do. This all would have been way easier 3-4 years ago when WebIDL was first being put together. :( -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
4 June 2014 TC39 Meeting Notes
# June 4 2014 Meeting Notes
Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip
Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth
Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK),
Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich
(BE), Mark Miller (MM), Peter Jensen (PJ)
## Adoption of the agenda
https://github.com/tc39/agendas/blob/master/2014/06.md
AWB: Adding section 8: Other ES6 Technical Issues
AWB: Adding Report from ECMA secretariat to HTML integration section
SK: Add an agenda item to discuss JSDoc and its use in editors
AWB: add ArrayBuffer neutering to ES6 agenda items
## Conclusion/Resolution
- Agenda Approved
- Minutes from April 2014 approved
## Scheduling of TC39 meeting
JN: Meeting schedule changes are problematic
- In november, we'll select for next year.
- The current meeting dates need to be approved now and committed to
YK: Didn't weigh scheduling concerns of champions vs. non-champions well
AWB: Hard to weigh those concerns until we know what will be talked about
Next:
- 29-31 July 2014 at Microsoft in Redmond, WA (USA)
- 23-25 September 2014 at Bocoup in Boston, MA (USA)
- 18-20 November 2014 at PayPal in San Jose, CA (USA)
(posted: http://www.ecma-international.org/memento/TC39-M.htm )
AWB: Should set agendas based on schedule, rather than other way around
JN: I will propose meeting dates in September for your consideration
## Agenda for this meeting
DH: Talk about generators tomorrow (Thursday), to accommodate Brendan Eich
and potentially Andy Wingo
## 4.2 Schedule Review
AWB: Goal was to present ES6 to ECMA general assembly for approval later
this year, meaning we need to approve finished draft at September meeting,
meaning we need a finished draft at July meeting. I don't see any way we
can have even an approximately finished draft by July. Also starting to get
good implementer feedback which is causing spec churn, but there are pieces
missing review. If we ratified what we have now we'd be missing serious
implementation feedback.
AWB: Propose we slip our publication target by 6 months. Spec will still be
feature frozen. We're just fixing bugs and accepting implementer feedback.
Concern 1: is this opening the door to feature creep? Important it doesn't
do that.
Concern 2: Will this simply delay implementer work by 6 months?
Concern 3: Perception of committee failure?
DH: We should move forward on the work and message that we're doing so.
Spec is not what drives the work, spec is the final capture of a stable
consensus. I'm OK with the spec slipping.
WH: Don't want to repeat E4X (ECMAScript-for-XML) experience of shipping
buggy spec, and later abandoning it.
?: Hazy distinction between calling something a bug vs. a revisited
conclusion.
WH: The issues with E4X were clearly bugs.
AWB: This committee can tell the difference between fixing bugs and
revisiting conclusions.
AWB: Focus energy on ES7 [if you want to revisit conclusions]!
AWB: Other factor playing into spec review is test262, to which we've just
gotten approval to accept contributions
JN: Can we approve the change of dates (presenting finished draft to TC39
committee in November rather than July)?
AWB: Everything we want to include is in the spec at some level of quality,
it's just a matter of ensuring quality.
YK: If you're an implementer, you shouldn't treat this as a slippage.
AWB: Should we start naming spec editions using years rather than an
incrementing number (ES2015 vs. ES6)?
AWB: Let's not throw this in with messaging about the schedule postponement.
YK: The fact that people are used to ES5/ES6/etc. will make the change
important as a messaging technique.
BE: Let's sleep on it.
## Conclusion/Resolution
- Postponement of presentation of final ES6 draft agreed upon
- Switch to yearly naming convention to be slept on
## Update on changes to spec since last meeting
AWB: See Draft Rev 25 section of
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
AWB: Object.prototype.toString.call(proxy) will be either [object Object]
or [object Function] depending on whether the proxy is callable, so that
there is no way to tell that an object is a Proxy
MM: Have to choose between use cases, and being able to hide Proxy-ness is
the better choice
AWB: Already considered/dropped isProxy, so using O.p.toString as a
back-door would have been inconsistent with that decision
AWB: Another Proxy issue MM and I talked about: custom property descriptor
attributes on Proxies, specifically adding additional attributes to the
descriptor that the Proxy could recognize.
```js
Object.defineProperty(obj, propName, {
value: whatever,
customAttribute: attrValue
});
// Should the
Re: 4 June 2014 TC39 Meeting Notes
Expanded Conclusion/Resolution for the ArrayBuffer neutering discussion: ## Conclusion/Resolution - Don't add isNeutered yet, and expect clients use try-catch when accessing properties to determine status. - Also remember to change the name. Released? Vacated? - Any attempt to access (read or write) binary data elements of an ArrayBuffer that has been neutered will throw a TypeError exception. - Accessing the byteLength property of an ArrayBuffer that has been neutered will throw TypeError exception. - Have not yet decided what happens to the the length, byteOffset, and byteLength properties of a TypedArray whose underlying ArrayBuffer gets neutered. - Keep the behavior that out of bounds reads of a TypedArray (whose buffer has not been neutered) returns undefined (MM: or throws, in strict mode) and that out of bounds write are no-ops (MM: throws in strict mode). TC39 recognizes that the above are breaking changes relative to the Khronos spec. but we believe that the behavior of silently treating neutered buffers as 0-length buffers is seriously flawed and would set a terrible precedent for any future transferable data types. Ben His errors are volitional and are the portals of discovery. -- James Joyce On Wed, Jun 11, 2014 at 9:08 AM, Ben Newman benja...@cs.stanford.edu wrote: # June 4 2014 Meeting Notes Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo (EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK), Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich (BE), Mark Miller (MM), Peter Jensen (PJ) ## Adoption of the agenda https://github.com/tc39/agendas/blob/master/2014/06.md AWB: Adding section 8: Other ES6 Technical Issues AWB: Adding Report from ECMA secretariat to HTML integration section SK: Add an agenda item to discuss JSDoc and its use in editors AWB: add ArrayBuffer neutering to ES6 agenda items ## Conclusion/Resolution - Agenda Approved - Minutes from April 2014 approved ## Scheduling of TC39 meeting JN: Meeting schedule changes are problematic - In november, we'll select for next year. - The current meeting dates need to be approved now and committed to YK: Didn't weigh scheduling concerns of champions vs. non-champions well AWB: Hard to weigh those concerns until we know what will be talked about Next: - 29-31 July 2014 at Microsoft in Redmond, WA (USA) - 23-25 September 2014 at Bocoup in Boston, MA (USA) - 18-20 November 2014 at PayPal in San Jose, CA (USA) (posted: http://www.ecma-international.org/memento/TC39-M.htm ) AWB: Should set agendas based on schedule, rather than other way around JN: I will propose meeting dates in September for your consideration ## Agenda for this meeting DH: Talk about generators tomorrow (Thursday), to accommodate Brendan Eich and potentially Andy Wingo ## 4.2 Schedule Review AWB: Goal was to present ES6 to ECMA general assembly for approval later this year, meaning we need to approve finished draft at September meeting, meaning we need a finished draft at July meeting. I don't see any way we can have even an approximately finished draft by July. Also starting to get good implementer feedback which is causing spec churn, but there are pieces missing review. If we ratified what we have now we'd be missing serious implementation feedback. AWB: Propose we slip our publication target by 6 months. Spec will still be feature frozen. We're just fixing bugs and accepting implementer feedback. Concern 1: is this opening the door to feature creep? Important it doesn't do that. Concern 2: Will this simply delay implementer work by 6 months? Concern 3: Perception of committee failure? DH: We should move forward on the work and message that we're doing so. Spec is not what drives the work, spec is the final capture of a stable consensus. I'm OK with the spec slipping. WH: Don't want to repeat E4X (ECMAScript-for-XML) experience of shipping buggy spec, and later abandoning it. ?: Hazy distinction between calling something a bug vs. a revisited conclusion. WH: The issues with E4X were clearly bugs. AWB: This committee can tell the difference between fixing bugs and revisiting conclusions. AWB: Focus energy on ES7 [if you want to revisit conclusions]! AWB: Other factor playing into spec review is test262, to which we've just gotten approval to accept contributions JN: Can we approve the change of dates (presenting finished draft to TC39 committee in November rather than July)? AWB: Everything we want to include is in the spec at some level of quality, it's just a matter of ensuring quality. YK: If you're an implementer,
