wycats at gmail.com
Fri Sep 25 23:33:20 PDT 2009
On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich <brendan at 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.
Developer | Engine Yard
More information about the es-discuss