Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

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

Received on Friday, 25 September 2009 23:55:35 UTC