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

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.

-- 
    Cheers,
    --MarkM