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 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'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 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 setPropertyIsEnumerable 3) Replace two-argument form of propertyIsEnumerable with __setPropertyIsEnumerable__ 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? > 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. Regards, Maciej _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
