ES4 draft: Object

Brendan Eich 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
> extent.
> 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  
group's work.

> 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
> issue.

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
> 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?

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.

/be




More information about the Es4-discuss mailing list