Re: typeof document.all

I'd really like to keep this conversation courteous and on the  
technical level. Treating every point of technical disagreement as an  
attack is not a good way to do that. Can we please do our best to  
assume mutual good faith?

On Oct 13, 2009, at 2:16 PM, Brendan Eich wrote:

> On Oct 13, 2009, at 12:06 PM, Maciej Stachowiak wrote:
>
>> On Oct 13, 2009, at 10:54 AM, Brendan Eich wrote:
>>
>>> I'm not sure this is an issue.
> [snip]
>>>
>>> Here's an overbroad google codesearch for " === undefined":
>>>
>>> http://www.google.com/codesearch?hl=en&lr=&q=lang%3Ajavascript+%22+%3D%3D%3D+undefined%22&sbtn=Search
>>>
>>> The results here IMHO argue for conservatism in the absence of  
>>> evidence, i.e., evaluating document.all in (document.all ===  
>>> undefined) to undefined.
>>
>> This search finds only one hit for "document.all === undefined",  
>> which is a Mozilla regression test:
>>
>> http://www.google.com/codesearch?hl=en&lr=&q=lang%3Ajavascript+%22document.all+%3D%3D%3D+undefined%22&sbtn=Search
>>
>> I could be convinced, but the Google code search does not seem  
>> terribly persuasive.
>
> Are you sure the codesearch I cited, for " === undefined", with lots  
> of generic-looking functions, is not showing code that sometimes  
> passes document.all as a parameter to one of the generic functions?  
> I'm not sure of that at all, which is why I argued for conservatism.
>
> Of course real results for "document.all === undefined" would be  
> persuasive, and I did start out writing "I'm not sure this is an  
> issue" as a followup to yesterday's mail promising to look into the  
> === issue further. You have to know when to quit!
>
> So forgive me for once again pointing out the difference between  
> what I wrote and what you seemed to respond to. I'm clearly not  
> claiming that we must specify that (document.all === undefined)  
> because of certain IE-only page compatibility knowledge, old or new  
> (there isn't any, and was not in 2004 now that I've read the old  
> bugs).
>
> I am suggesting that the more conservative course of treating  
> (document.all === undefined) is justified in light of all the  
> generic-looking "foo === undefined" testing that the codesearch I  
> cited discloses.

It's not a completely crazy rule to apply, but it's not obviously  
needed either. I'm indifferent to whether we enshrine this behavior in  
the spec. I don't think it would be a huge problem to implement it in  
WebKit, if we had to.

>
>
>>> Yes, a spec should be phrased in terms of ECMA-262's grammar. But  
>>> since you said what WebKit did, my response was equally concrete  
>>> in terms of SpiderMonkey. Are we done? I fear no good deed goes  
>>> unpunished.
>>
>> The only point I wanted to establish is that "do exactly what Gecko  
>> does" is probably not suitable for a spec, because the exact  
>> behavior seems to depend too much on SpiderMonkey-specific details.  
>> I can't even tell if you disagree with this point, since you're  
>> advocating a loose spec rather than a "do what Gecko does" spec.
>
> Come on, I don't think for a second we should spec what Mozilla  
> implemented, and I said so explicitly several times, the first one  
> (quoting: "I don't want to standardize what we did, but I am glad we  
> did it") here:
>
> http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0059.html
>
> You have me wrong, I'm not "defensive" about this. I'm increasingly  
> "offensive", mainly because you are not reading carefully.

I think the level of hostility in your replies is unwarranted. I'm  
trying to explore the solution space, by laying out the facts and  
drawing some conclusions. I know you already have a preferred approach  
for what the spec says, but I'd like to consider the options for  
myself. Reacting with hostility to this kind of exploration is not  
helpful.

> I also reject your  (apparently dropped) bogus point of order that  
> we must finish WebIDL's ES bindings and agree on how they work in  
> detail before considering document.all as a special case, possibly  
> underspecified.

I never said we "must" do that. Indeed I don't believe I ever  
references "finish[ing] Web IDL's ES bindings". What I did say on this  
topic is: (a) as a matter of present fact, Web IDL specifies which  
properties are own properties and which are on the prototype; (b) we  
may want to consider the general case of this (should it be specified  
at all? If so what should the spec require?) before considering the  
special case of document.all. I think your restatement is not a fair  
characterization of what I said.

>
>> I snipped all the other instances where you got irked at me for  
>> pointing out that the exact Gecko behavior is (in my opinion) not  
>> suitable to put in a spec as-is. No one is advocating that option  
>> so it doesn't seem important to discuss. If you do want to advocate  
>> a "do what Gecko does" spec then we can come back to this  
>> conversation.
>
> I think your dilemma of "WebKit or Gecko" is a false one. But if you  
> keep rehashing things, or failing to read what I wrote several  
> times, we'll never find an alternative.

I never presented those two options as the only alternatives. You may  
recall I listed five viable options for what we could do to the spec,  
one of which was the one you liked.

> We can do something else that underspecifies. I think we should.  
> I'll work on a proposal.

Great, thanks.

> The best way for you to make a proposal for ECMA-262 to allow an  
> object like WebKit's document.all is to propose it more-or-less as  
> you did in this thread (formalization is not required) to es-discuss@mozilla.org 
> .

All righty. I'll take a shot at recasting it in terms of what  
additional host object exceptions are needed.

Regards,
Maciej