On Sep 25, 2009, at 7:26 AM, Mark S. Miller wrote:
To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL->EcmaScript language binding.
The design of Web IDL itself is highly informed by the ECMAScript language binding - in fact, many Web IDL constructs exist solely for modeling ECMAScript APIs. So I don't think this split is useful
To answer a concern brought up later in the thread, neither is anyone of the EcmaScript committee proposing that anything be removed from WebIDL, or that the definition of these binding change in ways that create incompatibilities with current pre-HTML5 browser APIs. Whatever problems are created by legacy uses of WebIDL, we all accept that we have to live with these problems for the foreseeable future (essentially forever). Rather, the concern is that new APIs defined using WebIDL should not magnify these problems.
These are two separate points. The second point constitutes only advice from ECMA to W3C, and demonstrates a need for dialog. The EcmaScript committee has been evolving EcmaScript with one of our goals being to close the gap between what DOM objects can do and what EcmaScript objects can emulate. While we were busy trying to close the gap, html5 was busy widening it. This is largely our fault by not having communicated this goal. We seek dialog repair this mistake and to avoid repeating it.
I think there are two possible perspectives on what constitutes "magnify[ing] tthe problem" or "widening the gap"
A) Any new kind of requirement for implementations of object interfaces that can't be implemented in pure ECMAScript expands the scope of the problem. B) Any new interface that isn't implementable in ECMAScript widens the gap, even if it is for a reason that also applies to legacy
My view is A. That's why I pointed to legacy interfaces - if the construct can't go away from APIs in general, but we wish to implement all APIs in ECMAScript, then ultimately it is ECMAScript that must change, so using the same construct again doesn't create a new problem. Avoiding it in new APIs would provide a small amount of temporary relief for the brave person who seeks to implement the whole Web platform in pure ECMAScript, but in the long run would make no difference to the feasibility of the overall goal.
Now, there may be pragmatic reasons for avoiding catchall getters and setters:
1) Difficulty of efficient implementation (this is less true for index- only catchall getters). 2) Potential confusingness to authors (probably also less true for index access). 3) Namespace collisions between the magical attributes and the object's built-in attributes and methods - this makes it harder to specify and explain the interface and creates hazards for use (does not apply to the index access pattern afaict).
I think these are reasonable arguments (though I wouldn't rule out a priori that there may be situations where the API convenience of catchalls outweighs these concerns).
But I think these are totally separate from the "implementability in pure ECMAScript" concern. And in particular, I think index access to array-like objects is a good pattern that we should not stop using in APIs just because it's not implementable in pure ECMAScript today. Past interfaces use this pattern, and future interfaces should clearly use it once ECMAScript supports it. A temporary moratorium on using it would not be a wise tradeoff.
Regards, Maciej
