ES4 draft: Object
mjs at apple.com
Mon Mar 10 23:32:57 PDT 2008
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
> 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?
More information about the Es4-discuss