W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: [WebIDL] troublesome names, property attributes and related issues

From: Mark S. Miller <erights@google.com>
Date: Fri, 26 Aug 2011 08:00:43 -0700
Message-ID: <CABHxS9jKQT-h-9AttxoiGE+fwiWsKhe2_+yqtxZwHRW6o8J7Kw@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Cc: Simon Pieters <simonp@opera.com>, Jonas Sicking <jonas@sicking.cc>, public-script-coord@w3.org
On Fri, Aug 26, 2011 at 7:43 AM, Allen Wirfs-Brock <allen@wirfs-brock.com>wrote:

> I agree.  My original point was regarding whether the replication of
> constants on both interface objects and interface prototype object be wired
> into WebIDL (as it current is specified) or should it be done explicitly on
> a case by case basis  where it is needed for web compat for existing APIs.
> For example we could allow a "static" prefix on const definitions in which
> case Node might be coded as:
> interface Node {
>    ...
>    const unsigned short ELEMENT_NODE = 1;
>    static const unsigned short ELEMENT_NODE = 1;
>    ...
> }
> making it explicit that ELEMENT_NODE exists "on both sides".  New API's
> could be encouraged to adopted the more normal ECMAScript convention and
> only define the "static" constant.

Agreed again. This is a good example of a larger point that several of us
have made repeatedly: As a language for designing JavaScript APIs, WebIDL
systematically leads to bad API designs. These problems are not fixable
without replacing WebIDL, but we should do what we can to ameliorate these
problems. Allen's suggestion would help. When legacy compat forces us to use
WebIDL to express a bad API, it is good if WebIDL makes the API look more
obviously bad.

Received on Friday, 26 August 2011 15:01:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC