Subj : Re: Another JS question
To   : Sterling Bates
From : Brendan Eich
Date : Tue May 04 2004 03:36 pm

Sterling Bates wrote:
> Brendan Eich wrote:
> 
>> 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.
> 
> 
> Sounds good, how about adding this to the end of JS_ValueToObject's 
> current description:
> 
> "If v is NULL

NB: null, not NULL -- the JS reserved identifier is lowercase.  Note 
that I use the C standard macro NULL (all-caps) in context to mean a 
null pointer in C.


> or void

The unreserved identifier is named undefined, not void -- void is a 
unary operator, and the API speaks of VOID meaning undefined, but that's 
just to shorten things tolerably and line up with the C type, void.

So I would say "If v is null or undefined, ...."

> , JS_ValueToObject assigns NULL to objp

to *objp -- watch out for missing dereferencing.

> and returns 
> JS_TRUE. This is a known departure from the ECMA 262-3 specification, 
> which was written after SpiderMonkey. Developers who require ECMA 262-3 
> compliance may raise the issue in n.p.m.jseng."

Not sure I want the API docs pointing here.

> 
> (Proper <C></C> notation excluded for readability.)
> 
> Just as a question: would it work if js_ValueToObject checked 
> JSVERSION_IS_ECMA first, and was dynamically compliant vs traditional?

No, it would not be backward compatible.  We've been claiming ECMA 
conformance for a while now.  This is not a matter of conformance: the 
standard does not govern the JS API.  It's just a different thing, 
although related.  See also JS_ValueToECMAInt32 etc. and the ECMA-free 
counterparts.

/be

.