Subj : Re: Another JS question
To   : Sterling Bates
From : Brendan Eich
Date : Tue May 04 2004 11:27 am

Sterling Bates wrote:
> 
> http://lxr.mozilla.org/mozilla/source/js/src/jsobj.c#3613  The first 
> case, NULL or VOID, is permitted.
> 
> On the other hand, the ECMA 262-3 spec, page 53 
> (http://www.mozilla.org/js/language/E262-3.pdf):
> 
> Input Type     Result
> Undefined     Throw a TypeError exception.
> Null         Throw a TypeError exception.

Yes, the ECMA spec came after the JS implementation that evolved into 
SpiderMonkey, and one of the quirks of the JS_ValueToObject API is that 
it treats null and undefined as objects, return NULL in *objp.

This should be called out in the API docs.  If people need it, we could 
add a thin JS_ValueToNonNullObject.

>> Is there any way to identify an object that follows this "hash-like"
>> convention, so I can add a section in the conversion function to return a
>> native hash as the return value?
> 
> 
> I'm going to take a leap here and say "no".  Whether you index an object 
> using foo.bar or foo["bar"], javascript doesn't differentiate between 
> the two.  (At least, I haven't yet found anything in the spec to say 
> otherwise.)

I'm not sure that was Isaac's question.  But the point remains that if 
you are passed an Array that has had only named properties added to it, 
you should enumerate it using for..in, not by indexing from 0 to length, 
because length will be 0.

/be

.