Re: WebIDL

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

Received on Saturday, 26 September 2009 06:29:42 UTC