W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: WebIDL

From: Yehuda Katz <wycats@gmail.com>
Date: Fri, 25 Sep 2009 23:33:20 -0700
Message-ID: <245fb4700909252333y2ac503e5k1f925ffcdfce9694@mail.gmail.com>
To: Brendan Eich <brendan@mozilla.com>
Cc: Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org, HTML WG <public-html@w3.org>, es-discuss <es-discuss@mozilla.org>
On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich <brendan@mozilla.com> wrote:
> On Sep 25, 2009, at 11:05 PM, Yehuda Katz wrote:
>
>>> In the ES binding, the properties for these [Replaceable] attributes are
>>> effectively writable, but assigning to them breaks their link to the
>>> original attribute.  The assignment doesn’t perform any conversion from
>>> the ES value to the IDL type, either.  In other language bindings you
>>> would want these properties to behave like normal readonly attributes,
>>> e.g. in Java by having only a setter method.
>>
>> So this extension effectively converts a readonly attribute to a
>> writable one? Talk about confusing. And this isn't true about the same
>> attribute in non-ES contexts?!
>
> Please hold your fire. [Replaceable] was added in the 90s when Netscape 4
> and IE4 tried to evolve the DOM by adding properties to the global (window)
> object, and found the common names intended were already in use. It's a
> mistake to try to add common names, but try we did (both Netscape and
> Microsoft), with the hack of allowing the name to be preempted by content.
> Only if not "replaced" would the Netscape code actually reify the new
> property on demand. I'm not sure how IE did it.

Understood. I don't have the benefit of the history here
(unfortunately), just the specs as they stand today.

>
> This is an ongoing issue. Adding JSON (from json2.js) to ES5 involved some
> pain, due to other implementations of a JSON codec using the same name but
> different method names in the top-level JSON object. But it didn't require
> anything like [Replaceable] to sort out.
>
> We're stuck with [Replaceable], although like any sunk cost it is not
> cost-free and we could reengineer it. But what's the gain? Pointing out the
> silly way it makes readonly properties low-integrity is not helpful. Yes,
> you can "replace" (or preempt, I prefer) such properties with your own vars
> or functions in content. That was the way it worked in the 4th generation
> browsers. Why reengineer this minor piece of WebIDL now?

WebIDL, taken as a whole, make it very difficult for someone new to
the spec(s) to understand what's going on. I started, like a
reasonable person, by looking at the Window object. When looking at
it, I encountered a number of somewhat confusing constructs, like this
one. It is possible to have a long conversation where all of the
details are hashed out, but the reality is that the specs cannot be
easily understood without such a hashing.

I did not single out Replaceable in my efforts to understand.

>
> /be



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
Received on Saturday, 26 September 2009 06:34:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT