[WebIDL] summary of topics discussed at TC39 meeting

Here is a summary of the Web IDL-related topics that were discussed at
the TC39 meeting last week.  Corrections to my mis-rememberings/notings
welcome.  I expect various topics will generate discussion, so please
change the subject line if replying to a particular topic!


= Spec organisation =

There was concern primarily from MS people that having the ECMAScript
semantic extensions (i.e., custom [[DefineOwnProperty]], etc.) simply
woven through the text without explicitly calling them out as extensions
would (1) lead to spec writers using these features even though they
exist only to help define legacy features, and (2) make it hard for TC39
people to know what the set of extensions are so that eventually some of
them may come to be supported by the ECMAScript language itself.

I agreed to do some editorial work to make these extensions clear.

Another request was to link to real world examples for IDL features
where they exist, which is reasonable enough.  (Although it may not be
the case that all features will be used by the time Web IDL will need to
be frozen for publication.)


= Modules =

I had wondered whether the module construct should be hooked up to the
proposed ES Harmony module system.  We agreed this would be premature.

Modules at the moment won’t have an effect in the ECMAScript binding
(unless [NamespaceObject] is specified – this is being used by the BONDI
folks, IIRC).  Since the module story for ES is not yet straight, and
all existing web specifications expect interface objects to go on the
global object, I think I’m ready to suggest that spec writers using Web
IDL for web specifications not use modules at all for now.

One consideration is that Java interfaces for particular specs currently
need to be in particular packages – notably, DOM Events interfaces go in
org.w3c.dom.events and SVG interfaces go in org.w3c.dom.svg.  So far I
have seen no concrete benefit to this division, but for compatibility
with existing libraries these interfaces need to remain in those
packages.

When it comes to writing the next versions of DOM Events and SVG using
Web IDL, I suggest that prose be written to require the Java interfaces
be in their historical packages.  The IDL interfaces themselves wouldn’t
be placed within a module.


= Static members =

We discussed the desire to have static members, and there were no great
issues brought up with this.  We would allow them on both the “concrete”
and “abstract” interfaces.  As with constants, this would cause
properties to exist on the concrete interface’s interface object.


= Operation overloading =

There was a desire from everyone to simplify how overloading is
currently specified – perhaps to remove it altogether, if that is
possible.  I took an action to look into existing uses of overloading in
existing specifications, which I have begun and will post in more detail
about separately.


= Special operations =

There was mostly agreement that the special operations for getters,
setters, creators, deleters and callers are an anti-pattern – due to the
fact that they are un-JavaScripty (as a consequence of not being able to
be implemented by user script, at least without proxies) and because of
the collision issues with properties coming from prototypes – and should
be reserved for describing legacy APIs.  We would mark these as not
being suitable for new APIs.

There was a desire from some to allow Array to be subclassed in ES,
which would give a better foundation for the kinds of APIs like NodeList
and so on, which need to provide methods but also to expose a list of
values by index.  This would be the solution for new APIs wanting to
provide index getter kind of access to values (when it is eventually
worked on).


= int53_t and uint53_t =

There was not a strong objection to introducing these types.  It was
pointed out that ES might gain a 64-bit integer type (and bigints) in
the future, and that might cause 53-bit integer types to be irrelevant.
I think it was agreed that the harm isn’t significant, so if there is
demand for such types they can be introduced.

So: if anyone particularly wants these types for their specs
(IndexedDB?), let me know.


= Sequence and arrays =

People were happy with sequences except for the requirement on coercing
their elements to the right type when passing an Array (or some other
object with a length property) to an object expecting the sequence.  On
one hand, you’d like predictable coercion because the coercion can cause
side effects.  On the other hand, the Array might be very large, and the
operation you pass it to might only be interested in a single element,
so it would be wasteful to convert them all.

We ended up agreeing that Web IDL should suggest that specifications
spell out which elements are to be fetched and thus coerced, and in
which order.  We could have Web IDL state that unless otherwise
specified, each element of the sequence would be coerced in order.


For arrays, I had asserted that no specifications were using this yet,
and it was suggested then that they could be dropped until they were
specifically needed.  (In the future, the array type could map to
Blocks, or whatever mechanism for packed array data is introduced.)

Upon checking, I find that they are indeed some currenty users of the
array type, though, so we may have to revisit that decision. :-)

Here are the current uses:

  HTMLMediaElement::tracks
  http://www.whatwg.org/specs/web-apps/current-work/complete.html#media-elements

  ConnectionPeer::localStreams
  ConnectionPeer::remoteStreams
  http://www.whatwg.org/specs/web-apps/current-work/complete.html#connectionpeer
  (This is speculative stuff at the moment, so probably OK to break.)

  WebSocket constructor
  http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-websocket
  (This one should be changed to a sequence<DOMString>.)

  Element::attributes
  http://www.w3.org/TR/domcore/#dom-element-attributes


= Too few/many arguments passed to functions =

This is an issue that has changed a couple of times over the lifetime of
the spec.  Currently it says to throw if too few or too many arguments
are passed in.  The argument was made (as has been made by others) that
this is not very JavaScripty.  I had previously argued that by throwing
for incorrect actual parameter counts, we preserve these parameter
counts for future specs to use.  I was convinced last week that in fact
the opposite is better: by not throwing on too many arguments, we allow
APIs to evolve extra arguments while not breaking existing sites.

So we finally settled on ignoring extra arguments and coercing from
undefined for unspecified arguments as the most JavaScripty solution.
If anyone is particularly opposed to this, now would be a good time to
speak up, since I am interestd in changing the spec only one more time
on this issue. :)


= Multiple inheritance and mixins =

This is being discussed in this thread:
http://www.w3.org/mid/20101119213926.GF8734@wok.mcc.id.au


= DOM exceptions inheriting from Error =

Everyone was happy with the suggestion to make DOMException’s prototype
be Error.prototype.


= Property enumeration order =

This was brought up because of
https://bugzilla.mozilla.org/show_bug.cgi?id=524423.  It seems TC39 is
interested in specifying property enumeration order at some time in the
future.  I don’t particularly want to specify property enumeration order
in general in Web IDL.  It might be that specific objects require
enumeration order for compatibility.  This issue probably wasn’t
discussed in enough detail last week: TC39 people, if it was deemed
important to specify property enumeration order (or a partial order, at
least) for certain objects, would there be any objection to Web IDL
specifying that?

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 24 November 2010 02:55:21 UTC