- From: Yehuda Katz <wycats@gmail.com>
- Date: Fri, 25 Sep 2009 23:33:20 -0700
- 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 UTC