Re: typeof document.all

On Oct 13, 2009, at 3:52 PM, Maciej Stachowiak wrote:

> On Oct 13, 2009, at 3:40 PM, Brendan Eich wrote:
>
>> I see your point: if we have an object that masquerades as  
>> undefined, you might want === to compare object identity, as for  
>> all other objects. Given your approach of using an object with non- 
>> ECMA semantics, keeping === comparing object identities pending  
>> evidence that IE-only web page compatibility needs (document.all  
>> === undefined) is plausible and could be a good thing.
>>
>> Indeed are you indifferent or would making (document.all ===  
>> undefined) deoptimize your === code?
>
> It's possible it would slightly deoptimize it, in some cases. The  
> impact would depend on how readily we can segregate objects that  
> masquerade as undefined from normal objects, which are cheap to  
> compare with ===. I haven't studied in detail. So I guess I'd rather  
> not do it unless it turns out to be needed.

Ok, I'll keep this in mind in developing a "third way" proposal --  
it's a completely fair point against making (document.all ===  
undefined).


>> Maybe it doesn't matter; == is much more commonly used with any  
>> operands, although JSLint and Doug Crockford's book evangelize ===  
>> exclusively as the replacement for ==, and I've seen more code  
>> using === over time on the public web.
>
> Is there a substantial overlap between sites that use JSLint and  
> sites that use document.all? That's the bit I'm not sure of.

It's undemonstrated, just one of those things that we've all seen  
happen. People mix old and new code at the script tag and pages-in- 
frames levels. All those generic-looking "foo === undefined" testing  
functions still give me pause, but they aren't conclusive. More rarely  
someone naively "updates" old code with new practices but doesn't know  
to treat magic host objects with care.


> Note: in WebKit, ("all" in document) is true. We could very easily  
> make it false, and that might be a slight compatibility boost too.  
> Could not find much evidence of that construct on Google Code  
> Search, even though it is arguably the cleanest way to do feature  
> detection.

Yeah, it's from ES3, so "too new". People prefer a falsy test,  
especially if inverted with !, which requires parenthesizing the "in"  
expression:

if (!("all" in document)) { non-IE content? }

vs.

if (!document.all) { non-IE content! }

The quotes and spaces hurt too. There's a low-level keystroke-counting  
economics at war with longer forms in JS, it tells over time on the Web.


> Perhaps this was naiive, but I thought there was a chance that the  
> Gecko behavior might be something that *was* suitable to spec, and  
> which might be reasonably straightforward to implement, in which  
> case if we all agreed to implement it we could have world peace and  
> interoperability and all that good stuff.

I share your frustration -- we were in a hurry in 2004 and we didn't  
want to try for magic object semantics that would stretch our meta- 
object APIs. Our approach was de-minimus from certain points of view.

Thinking this through, I have two general approaches for alternative 3  
in mind, hope it's ok to throw them out quickly:

(3a) underspecify document.all as a host object property that may be  
reliably tested only by if, &&, ||, == null, == undefined, and ! and  
the != counterparts. Anything else is unspecified behavior.

(3b) specify document.all as an ES-Harmony value type, details TBD but  
this allows overloading operators including ! and == but not === (at  
least not in the discussions we've had yet), and overloading ToBoolean.

The idea is to allow library authors to add Decimal, Rational,  
Complex, Quaternion, RGBColor, BigNum, etc. etc. without requiring  
Ecma TC39 to gate-keep and slow down evolution of new operator-enabled  
value types (mainly numeric types, but not only those kinds of  
values). Literal syntax would be part of the deal, so 'if (0m)' for  
decimal literal 0 tests that Decimal instance as falsy, just like the  
Number type instance 0 in JS today. There's your  
ToBoolean(valueTypeInstance) -> false right there ;-).

(3b) would give us fine-grained control over how document.all's value  
is interpreted when used with various operators and in Boolean  
contexts. But it would depend on the value types work coming to  
fruition.

I have some value types work to do in http://wiki.ecmascript.org/,  
about which I'll notify es-discuss as soon as the wiki page is up.  
Again sorry for sketching here, I hope this is reasonably clear. I  
crave early feedback to avoid going astray.

Reactions to (3a) in its own right, and to (3b)?

/be

Received on Tuesday, 13 October 2009 23:29:40 UTC