[Bug 12845] Disallow shadowing attributes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12845

Allen Wirfs-Brock <allen@wirfs-brock.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allen@wirfs-brock.com

--- Comment #4 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2011-06-01 16:43:29 UTC ---
(In reply to comment #2)
> Are there other examples of this than HTMLOptionsCollection.length? Do we
> expect others to appear?
> 
> This is a pretty strange so it seems likely to me that the answer to the above
> two questions is "no".
> 

I think it would be fine for the Web IDL ES binding to explicitly say that the
getter is copied down in these situations. I think this matches the expectation
of interface designers.  If you really want to over-ride both the getter and
setter you would need to explicitly specify that anyway.

The problem of clobbering the getter when defining a setter actually occurs
anytime you use javascript objects to represent mix'n'match access and update
behaviors that can be combined via prototype inheritance.

See for example, here is code fragment from
https://github.com/allenwb/jsmirrors/blob/master/mirrors.js that exhibits it:

function mixinFunctionJSONMutableMirror(proto) {
   return Obj.create(proto,{
      //Implements functionMutableMirrorInterface
      name: {get: inheritedGetter(proto,"name"),
        set: function(n)
{this.__domain[this.__ser].name=jsonReflectedValue(n)}},
      source: {get: inheritedGetter(proto,"source"),
        set: function(s) {this.__domain[this.__ser].src=jsonReflectedValue(s)}}
    });
};

Note that getters had to be explicitly defined in a manner that that "copy
down" the inherited getter.

There is even a proposal for adding syntax to ES.next to explicitly support
this pattern.  See
http://wiki.ecmascript.org/doku.php?id=strawman:object_initialiser_super

-- 
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, 1 June 2011 16:43:33 UTC