ES4 draft: Object
mjs at apple.com
Mon Mar 10 23:14:29 PDT 2008
On Mar 10, 2008, at 7:01 PM, Lars Hansen wrote:
>> We are the WG. Are you saying that substantive discussions
>> of your proposals are not welcome? Not sure what the point
>> of participating is if that's the case.
> Sorry, I didn't realize that "I find it abhorrent" qualified as
> substantive discussion. My fault. Won't happen again.
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'm dealing with a serious insurrection of folks who believe
>> that the ES4 working group has a bad attitude, based on
>> Brendan's public comments and responses to issues like this
>> one. They're quite visible.
> 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
issue. I'd like to propose the following three alternatives to the
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
What is the process for the WG deciding whether to make one of these
changes, or something else?
> 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.
More information about the Es4-discuss