ES4 draft: Object
brendan at mozilla.org
Tue Mar 11 11:22:53 PDT 2008
On Mar 11, 2008, at 1:14 AM, 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.
I agree with these points.
> 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),
No, that was not the only reason. The other reason (it may be a bad
reason, but I pointed it out in an earlier message to make it
apparent): so calls passing two arguments would not cause ES3
implementations to fail as would "undetected" calls to a new method.
But I agree that the numbered points you make are sufficient to
reconsider the two-argument proposal that was accepted a while go.
Just for the es4-discuss list's information, I want to provide some
historical context. the working group at that time had many large and
small issues to grapple with, so we did not dedicate too much time to
the "Prototype Ajax library" problem (wanting to set DontEnum on user-
defined properties). We were not so much in favor of the _de minimus_
second argument idea that was quickly settled on, as we were opposed
to adding another method with a plain name to Object.prototype. And
even that wasn't a strong objection, in light of namespaces (more
below on that).
This was at the time very much "small potatoes", which I for one am
happy to revisit (I've already sketched a namespace-based
alternative). It should not be used to impeach the entirely of the
> I propose that it is overblown. Mozilla has defined new
> methods and properties on all objects.
In 1998 or 1999, we added "meta" methods and properties,
distinguished (after Python) by leading and trailing double underscores.
We haven't tried adding a plainly named property to Object.prototype
in quite a while.
> 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__.
These are all metaprogramming hooks, but so arguably is
__setPropertyIsEnumerable__ -- so I agree with your reasoning here.
> Has any study been done on how many sites currently make use of the
> property names of a likely setter for propertyIsEnumerable?
We have not crawled the web looking for plain-named methods, but we
have spidered for other patterns we proposed to change incompatibly,
and the results are not decisive. For example, looking for attempts
to rebind standard constructors found only a dead MSN .js file
rebinding Error, but when we tried in Firefox 3 beta 2 to lock down
the global bindings for Date, etc., we found many sites and web apps
breaking. This is a different case, of course, but my point stands:
searching the web is informative, but not decisive.
>> Debate is only good. I merely pointed out the obvious thing, namely
>> that until there is an alternative proposal written up to deal with
>> this issue, the current design stands unless the WG, as a group,
>> decides to just get rid of it (leaving the problem it was designed
>> to solve solution-less).
> Surely reviewing this spec is the appropriate time to revisit this
Yes, and this list is the right place. It's pretty clear Lars agrees,
and nothing he wrote cited above contradicts it. So let's discuss more.
> I'd like to propose the following three alternatives to the
> current proposal:
> 1) Remove the feature entirely from ES4 (as part of the "judicious
> feature cuts" process) until a more appropriate syntax is found
> 2) Replace two-argument form of propertyIsEnumerable with
> 3) Replace two-argument form of propertyIsEnumerable with
> I think each of these options is so trivial as to not require a
> lengthy write-up.
> What is the process for the WG deciding whether to make one of these
> changes, or something else?
Arguing here in es4-discuss might be enough, if the argument makes
progress and the participants reach a consensus.
>> I like the idea of making non-public-namespaced properties be
>> not-enumerable and getting rid of DontEnum. We've talked loosely
>> about it for a while. But it's remained loose talk, it has never
>> made it to the stage where it is a coherent proposal.
> I don't like syntax-based alternatives since they cannot be made to
> degrade gracefully in ES3 UAs.
I think that's a good point too, since as noted above it was one of
the two reasons for the lame-duck two-argument proposal we've accepted.
More information about the Es4-discuss