ES4 draft: Object

Maciej Stachowiak mjs at
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
> 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?


More information about the Es4-discuss mailing list