Here are my very rough notes for today's IDL discussions. In many
cases I couldn't tell what was actually decided rather than merely
discussed.
Waldemar
IDL day: Lots of discussions, exploring various points and making
suggestions. Mostly exploratory -- not in the proper frame today to
reach significant concrete conclusions.
Allen: WebIDL encouraged specification of APIs that are awkward or
detrimental in ECMAScript
Alex: Bad API example: DOM collections
Allen: Legacy features should be segregated and labeled "legacy" and
not used to design new APIs. Specification feels like the APIs were
designed for Java and then adapted to JavaScript.
Points from this meeting are "deja vu" repeats of the points from the
2009 November meeting.
Oliver: IDL mappings onto ECMAScript details like prototypes are underspecified.
Allen: Overload resolution should not be used as an extension of the
call internal method. Instead, how the function behaves with
arguments of various types should be specified.
If ECMAScript is the primary target, why have multiple inheritance?
It's for SVG. Debated the usefulness and appropriateness of multiple
inheritance in WebIDL.
Lunch discussion about the merits of adding a cleaner array type.
Some implementations currently cheat on ES5 semantics on arrays,
failing to run a setter in a prototype when writing into a hole in an
array. Mozilla detects this case and managed to do it right.
Debate over specification of rejection of mistyped arguments by
algorithms (as in ES5) or by implicit type-validation rules together
with an IDL type signature.
WebIDL: There are only a limited number of places where a native
object may be used.
Discussion of annotation of ownership transfers across APIs in the
context of synchronous callbacks or retention of references by the
callee in some global data structure. When is it safe to pass mutable
state?
Presentation request: Wish that specification of WebIDL were linked
to real API examples where those IDL features were used.
What are the problems with making NodeList inherit from Array?
Interface and mixin discussion.
Brendan: If WebIDL interfaces are abstract, they shouldn't be
reflected into ECMAScript. (If they were, instanceof would be
problematic because the ECMAScript prototype chain doesn't support
mixin multiple inheritance.)
What should "new NodeList" do?
Conclusion: Abstract interfaces are not reflected into ECMAScript.
interface Node
interface EventTarget
Node implements EventTarget
Interface Element: Node
Prototype chain of an instance of Element is:
Element.prototype
Node.prototype
Object.prototype
MarkM: Do we really need abstract interfaces inheriting from abstract
interfaces? This is complicating the spec-to-ECMAScript-API
translation.
Those are useful in cases such as DOM 1 nodes vs. DOM 2 nodes. Debated.
Need good names for how to refer to reified vs. spec sugar interfaces.
Allen: Move all IDL places that can't be expressed natively in
ECMAScript into a separate section of the spec.
We agree that host object extensions should be as small as possible.
Discussed the merits of overloading vs. union types.
For an overloaded method that takes instances of one of two different
interfaces, passing null will satisfy both interfaces. In this case
IDL says that both overloads of the method should do the same thing
with null.
If you define a parameter with a union type I1|I2 where I1 and I2 are
abstract interface types, the callee has no way to distinguish whether
the argument is a member of I1 or I2 because abstract interface types
are not reified. Thus the caller can only invoke methods that are
common to I1 and I2.
Do we need unions of abstract interface types?
Waldemar: IDL "getter" and "setter" are confusing. Defining
interface I {
getter float foo(...) ...
}
will define every every property on instances of I to be a getter
except for the foo property, which is a regular method.
53-bit int type? Current IDL long long type is hackish -- it allows
loss of precision beyond 2^53. On the other hand, there is a proposal
to introduce high-precision integers into ECMAScript, so 53-bit ints
seems like another hack.
Here are my very rough notes for today's IDL discussions. In many
cases I couldn't tell what was actually decided rather than merely
discussed.
Waldemar
--------
IDL day: Lots of discussions, exploring various points and making
suggestions. Mostly exploratory -- not in the proper frame today to
reach significant concrete conclusions.
Allen: WebIDL encouraged specification of APIs that are awkward or
detrimental in ECMAScript
Alex: Bad API example: DOM collections
Allen: Legacy features should be segregated and labeled "legacy" and
not used to design new APIs. Specification feels like the APIs were
designed for Java and then adapted to JavaScript.
Points from this meeting are "deja vu" repeats of the points from the
2009 November meeting.
Oliver: IDL mappings onto ECMAScript details like prototypes are underspecified.
Allen: Overload resolution should not be used as an extension of the
call internal method. Instead, how the function behaves with
arguments of various types should be specified.
If ECMAScript is the primary target, why have multiple inheritance?
It's for SVG. Debated the usefulness and appropriateness of multiple
inheritance in WebIDL.
Lunch discussion about the merits of adding a cleaner array type.
Some implementations currently cheat on ES5 semantics on arrays,
failing to run a setter in a prototype when writing into a hole in an
array. Mozilla detects this case and managed to do it right.
Debate over specification of rejection of mistyped arguments by
algorithms (as in ES5) or by implicit type-validation rules together
with an IDL type signature.
WebIDL: There are only a limited number of places where a native
object may be used.
Discussion of annotation of ownership transfers across APIs in the
context of synchronous callbacks or retention of references by the
callee in some global data structure. When is it safe to pass mutable
state?
Presentation request: Wish that specification of WebIDL were linked
to real API examples where those IDL features were used.
What are the problems with making NodeList inherit from Array?
Interface and mixin discussion.
Brendan: If WebIDL interfaces are abstract, they shouldn't be
reflected into ECMAScript. (If they were, instanceof would be
problematic because the ECMAScript prototype chain doesn't support
mixin multiple inheritance.)
What should "new NodeList" do?
Conclusion: Abstract interfaces are not reflected into ECMAScript.
interface Node
interface EventTarget
Node implements EventTarget
Interface Element: Node
Prototype chain of an instance of Element is:
Element.prototype
Node.prototype
Object.prototype
MarkM: Do we really need abstract interfaces inheriting from abstract
interfaces? This is complicating the spec-to-ECMAScript-API
translation.
Those are useful in cases such as DOM 1 nodes vs. DOM 2 nodes. Debated.
Need good names for how to refer to reified vs. spec sugar interfaces.
Allen: Move all IDL places that can't be expressed natively in
ECMAScript into a separate section of the spec.
We agree that host object extensions should be as small as possible.
Discussed the merits of overloading vs. union types.
For an overloaded method that takes instances of one of two different
interfaces, passing null will satisfy both interfaces. In this case
IDL says that both overloads of the method should do the same thing
with null.
If you define a parameter with a union type I1|I2 where I1 and I2 are
abstract interface types, the callee has no way to distinguish whether
the argument is a member of I1 or I2 because abstract interface types
are not reified. Thus the caller can only invoke methods that are
common to I1 and I2.
Do we need unions of abstract interface types?
Waldemar: IDL "getter" and "setter" are confusing. Defining
interface I {
getter float foo(...) ...
}
will define every every property on instances of I to be a getter
*except* for the foo property, which is a regular method.
53-bit int type? Current IDL long long type is hackish -- it allows
loss of precision beyond 2^53. On the other hand, there is a proposal
to introduce high-precision integers into ECMAScript, so 53-bit ints
seems like another hack.
Here are my very rough notes for today's IDL discussions. In many cases I couldn't tell what was actually decided rather than merely discussed.
IDL day: Lots of discussions, exploring various points and making suggestions. Mostly exploratory -- not in the proper frame today to reach significant concrete conclusions.
Allen: WebIDL encouraged specification of APIs that are awkward or detrimental in ECMAScript Alex: Bad API example: DOM collections Allen: Legacy features should be segregated and labeled "legacy" and not used to design new APIs. Specification feels like the APIs were designed for Java and then adapted to JavaScript.
Points from this meeting are "deja vu" repeats of the points from the 2009 November meeting.
Oliver: IDL mappings onto ECMAScript details like prototypes are underspecified.
Allen: Overload resolution should not be used as an extension of the call internal method. Instead, how the function behaves with arguments of various types should be specified.
If ECMAScript is the primary target, why have multiple inheritance? It's for SVG. Debated the usefulness and appropriateness of multiple inheritance in WebIDL.
Lunch discussion about the merits of adding a cleaner array type.
Some implementations currently cheat on ES5 semantics on arrays, failing to run a setter in a prototype when writing into a hole in an array. Mozilla detects this case and managed to do it right.
Debate over specification of rejection of mistyped arguments by algorithms (as in ES5) or by implicit type-validation rules together with an IDL type signature.
WebIDL: There are only a limited number of places where a native object may be used.
Discussion of annotation of ownership transfers across APIs in the context of synchronous callbacks or retention of references by the callee in some global data structure. When is it safe to pass mutable state?
Presentation request: Wish that specification of WebIDL were linked to real API examples where those IDL features were used.
What are the problems with making NodeList inherit from Array?
Interface and mixin discussion.
Brendan: If WebIDL interfaces are abstract, they shouldn't be reflected into ECMAScript. (If they were, instanceof would be problematic because the ECMAScript prototype chain doesn't support mixin multiple inheritance.)
What should "new NodeList" do?
Conclusion: Abstract interfaces are not reflected into ECMAScript. interface Node interface EventTarget Node implements EventTarget Interface Element: Node
Prototype chain of an instance of Element is: Element.prototype Node.prototype Object.prototype
MarkM: Do we really need abstract interfaces inheriting from abstract interfaces? This is complicating the spec-to-ECMAScript-API translation.
Those are useful in cases such as DOM 1 nodes vs. DOM 2 nodes. Debated.
Need good names for how to refer to reified vs. spec sugar interfaces.
Allen: Move all IDL places that can't be expressed natively in ECMAScript into a separate section of the spec.
We agree that host object extensions should be as small as possible.
Discussed the merits of overloading vs. union types.
For an overloaded method that takes instances of one of two different interfaces, passing null will satisfy both interfaces. In this case IDL says that both overloads of the method should do the same thing with null.
If you define a parameter with a union type I1|I2 where I1 and I2 are abstract interface types, the callee has no way to distinguish whether the argument is a member of I1 or I2 because abstract interface types are not reified. Thus the caller can only invoke methods that are common to I1 and I2.
Do we need unions of abstract interface types?
Waldemar: IDL "getter" and "setter" are confusing. Defining interface I { getter float foo(...) ... } will define every every property on instances of I to be a getter except for the foo property, which is a regular method.
53-bit int type? Current IDL long long type is hackish -- it allows loss of precision beyond 2^53. On the other hand, there is a proposal to introduce high-precision integers into ECMAScript, so 53-bit ints seems like another hack.
Here are my very rough notes for today's IDL discussions. In many cases I couldn't tell what was actually decided rather than merely discussed. Waldemar -------- IDL day: Lots of discussions, exploring various points and making suggestions. Mostly exploratory -- not in the proper frame today to reach significant concrete conclusions. Allen: WebIDL encouraged specification of APIs that are awkward or detrimental in ECMAScript Alex: Bad API example: DOM collections Allen: Legacy features should be segregated and labeled "legacy" and not used to design new APIs. Specification feels like the APIs were designed for Java and then adapted to JavaScript. Points from this meeting are "deja vu" repeats of the points from the 2009 November meeting. Oliver: IDL mappings onto ECMAScript details like prototypes are underspecified. Allen: Overload resolution should not be used as an extension of the call internal method. Instead, how the function behaves with arguments of various types should be specified. If ECMAScript is the primary target, why have multiple inheritance? It's for SVG. Debated the usefulness and appropriateness of multiple inheritance in WebIDL. Lunch discussion about the merits of adding a cleaner array type. Some implementations currently cheat on ES5 semantics on arrays, failing to run a setter in a prototype when writing into a hole in an array. Mozilla detects this case and managed to do it right. Debate over specification of rejection of mistyped arguments by algorithms (as in ES5) or by implicit type-validation rules together with an IDL type signature. WebIDL: There are only a limited number of places where a native object may be used. Discussion of annotation of ownership transfers across APIs in the context of synchronous callbacks or retention of references by the callee in some global data structure. When is it safe to pass mutable state? Presentation request: Wish that specification of WebIDL were linked to real API examples where those IDL features were used. What are the problems with making NodeList inherit from Array? Interface and mixin discussion. Brendan: If WebIDL interfaces are abstract, they shouldn't be reflected into ECMAScript. (If they were, instanceof would be problematic because the ECMAScript prototype chain doesn't support mixin multiple inheritance.) What should "new NodeList" do? Conclusion: Abstract interfaces are not reflected into ECMAScript. interface Node interface EventTarget Node implements EventTarget Interface Element: Node Prototype chain of an instance of Element is: Element.prototype Node.prototype Object.prototype MarkM: Do we really need abstract interfaces inheriting from abstract interfaces? This is complicating the spec-to-ECMAScript-API translation. Those are useful in cases such as DOM 1 nodes vs. DOM 2 nodes. Debated. Need good names for how to refer to reified vs. spec sugar interfaces. Allen: Move all IDL places that can't be expressed natively in ECMAScript into a separate section of the spec. We agree that host object extensions should be as small as possible. Discussed the merits of overloading vs. union types. For an overloaded method that takes instances of one of two different interfaces, passing null will satisfy both interfaces. In this case IDL says that both overloads of the method should do the same thing with null. If you define a parameter with a union type I1|I2 where I1 and I2 are abstract interface types, the callee has no way to distinguish whether the argument is a member of I1 or I2 because abstract interface types are not reified. Thus the caller can only invoke methods that are common to I1 and I2. Do we need unions of abstract interface types? Waldemar: IDL "getter" and "setter" are confusing. Defining interface I { getter float foo(...) ... } will define every every property on instances of I to be a getter *except* for the foo property, which is a regular method. 53-bit int type? Current IDL long long type is hackish -- it allows loss of precision beyond 2^53. On the other hand, there is a proposal to introduce high-precision integers into ECMAScript, so 53-bit ints seems like another hack.