Catch-all pattern in DOM APIs considered harmful (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

# David-Sarah Hopwood (16 years ago)

Anne van Kesteren wrote:

On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby <rubys at intertwingly.net> wrote:

Meanwhile, what we need is concrete bug reports of specific instances where the existing WebIDL description of key interfaces is done in a way that precludes a pure ECMAScript implementation of the function.

Is there even agreement that is a goal?

I personally think the catch-all pattern which Brendan mentioned is quite convenient and I do not think it would make sense to suddenly stop using it.

It does make sense to stop using it. Typical uses of this pattern result in a collision between two namespaces: a namespace of objects defined in HTML/XML (named by IDs for example), and the namespace of methods in a DOM object. This causes problems if an ID matches a method name, and requires programmers to use a different syntax if an ID name is not an ECMAScript identifier. It is much clearer to define an explicit 'get' method, similar to 'getElementById' for example.

Also, the idea of removing the feature from Web IDL so that future specifications cannot use it is something I disagree with since having it in Web IDL simplifies writing specifications for the (legacy) platform and removes room for error.

The suggestion was only to stop using the catch-all pattern for new APIs, not to remove it.

Anne van Kesteren wrote:
> On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby <rubys at intertwingly.net>
> wrote:
>> Meanwhile, what we need is concrete bug reports of specific instances
>> where the existing WebIDL description of key interfaces is done in a
>> way that precludes a pure ECMAScript implementation of the function.
> 
> Is there even agreement that is a goal?
> 
> I personally think the catch-all pattern which Brendan mentioned is
> quite convenient and I do not think it would make sense to suddenly stop
> using it.

It does make sense to stop using it. Typical uses of this pattern
result in a collision between two namespaces: a namespace of objects
defined in HTML/XML (named by IDs for example), and the namespace of
methods in a DOM object. This causes problems if an ID matches a method
name, and requires programmers to use a different syntax if an ID name
is not an ECMAScript identifier. It is *much* clearer to define an
explicit 'get' method, similar to 'getElementById' for example.

> Also, the idea of removing the feature from Web IDL so that
> future specifications cannot use it is something I disagree with since
> having it in Web IDL simplifies writing specifications for the (legacy)
> platform and removes room for error.

The suggestion was only to stop using the catch-all pattern for new APIs,
not to remove it.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

# David-Sarah Hopwood (16 years ago)

Maciej Stachowiak wrote:

Let me give a concrete example, the HTMLCollection interface from HTML5: dev.w3.org/html5/spec/Overview.html#htmlcollection-0.

This interface is defined to have "getter" properties which imply catchall getters for index and non-index properties. This is implemented by all existing browsers and is needed for compatibility with a lot of Web content. It is also required by DOM Level 2 HTML's ECMAScript bindings: www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html. The fact that ECMAScript 5 can't implement an interface that behaves like this is an ECMAScript issue, not an HTML issue, in my opinion, and one that will hopefully be fixed in future editions.

Note that if a future edition of ECMAScript were to support catch-alls, it would still not be a good idea to define any new APIs similar to HTMLCollection, that have the problem of names defined in HTML/XML/CSS potentially colliding with ECMAScript method names (or method names in other languages). Such APIs are confusing, error-prone, and detrimental to forward compatibility and language independence.

Maciej Stachowiak wrote:
> Let me give a concrete example, the HTMLCollection interface from HTML5:
> <http://dev.w3.org/html5/spec/Overview.html#htmlcollection-0>.
> 
> This interface is defined to have "getter" properties which imply
> catchall getters for index and non-index properties. This is implemented
> by all existing browsers and is needed for compatibility with a lot of
> Web content. It is also required by DOM Level 2 HTML's ECMAScript
> bindings:
> <http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>. The
> fact that ECMAScript 5 can't implement an interface that behaves like
> this is an ECMAScript issue, not an HTML issue, in my opinion, and one
> that will hopefully be fixed in future editions.

Note that if a future edition of ECMAScript were to support catch-alls,
it would still not be a good idea to define any new APIs similar to
HTMLCollection, that have the problem of names defined in HTML/XML/CSS
potentially colliding with ECMAScript method names (or method names in
other languages). Such APIs are confusing, error-prone, and detrimental
to forward compatibility and language independence.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com