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.
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?
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
