On Mar 10, 2008, at 11:14 PM, Maciej Stachowiak wrote: > The optional second argument to make propertyIsEnumerable a setter has > some practical problems: > > 1) It violates the very strong norm that getter and setter functions > are separate and have their own different arguments. It will make the > feature harder to use and code using it harder to understand, to some > extent. > 2) It makes it impossible to feature test for the ability to disable > enumerability, compared to a separate setter. > > Against the argument that it is too risky compatibility-wise to add a > new method to the object prototype (apparently the only reason things > were done), I propose that it is overblown. Mozilla has defined new > methods and properties on all objects. We have copied some in Safari > and seen no web compatibility issues, I assume Mozilla has not had any > as well. Specifically, I am thinking of __defineSetter__, > __defineGetter__, __lookupSetter__, __lookupGetter__, and __proto__. > > Has any study been done on how many sites currently make use of the > property names of a likely setter for propertyIsEnumerable?
I forgot to mention, making two-argument propertyIsEnumerable have setter semantics can be a tiny compatibility risk too, if any code accidentally calls it with two args and does not expect it to act as a setter in this case. Do we have any way to quantify the relative compatibility risk of the current design vs. a separate setter? Regards, Maciej _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
