- From: <bugzilla@jessica.w3.org>
- Date: Wed, 08 Jun 2011 00:31:25 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12845 --- Comment #19 from Cameron McCormack <cam@mcc.id.au> 2011-06-08 00:31:24 UTC --- (In reply to comment #18) > I think there were two actual issues at the beginning of this thread. First,if > a super-interface says some attribute (property in JS terms) is readonly can an > interface derived from it make that same attribute read/write. The answer > should be yes. Adding write behavior is a specialization which is valid > subtyping behavior. (this seems like a WebIDL question that should be > independent of language bindings) I agree this should be allowed. > The second issue is how does this map to JS if the attributes correspond to JS > accessor properties as JS can't define an accessor set function without also > defining its get function. This is presumably an issue for the WebIDL > ECMAScript binding. My suggest is that the answer is that an implementation of > the derived writable interface must also implement the required inherited read > behavior. It can do this either by making the get side of the accessor > delegate to the over-ridden get implementation or by providing a new get-side > implementation that does the required. It really seems more like an > implementation decision rather than something that needs to be specified in the > Es binding. Whether the implementation has an independent implementation of the get behaviour or whether it defers to the super-interface's getter does sound like an implementation decision. But one thing that is visible to scripts is whether the actual getter on the two properties' descriptors are the same Function object or not. Web IDL doesn't say currently whether these Function objects need to be distinct objects or not. The more general issue, whether overriding with different behaviour should be allowed by Web IDL or not, I'm still unsure about. The problem is with *incompatible* behaviour, right? Different behaviour is OK, as long as it is consistent with the promises made by the definition of the super-interface. The difference between "different" and "incompatible" behaviour isn't one we can check for in the IDL. If we think that "different but compatible" behaviour will never come up when designing Web APIs, then we can get a small win by disallowing overriding in general (apart from the readonly-becoming-writable issue). OTOH, we could just file bugs on the specifications that specify incompatible behaviour on sub-interfaces as we find them... -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Wednesday, 8 June 2011 00:31:31 UTC