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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
