4 June 2014 TC39 Meeting Notes

[David Bruant]

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 `Promise<T>` 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 `Promise<T>` 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