a problem with JS_ValueToBoolean.

[itaj sherman]

JS_ValueToBoolean seem to work different than other JS_ValueTo*.
when i call any of the others on an object value, they invoke the conversion
functions (i didn't replace the convertStub) which then invoke valueOf or
toString.
JS_ValueToBoolean doesn't do that, instead it always return true for any
object (but null).

so, i want that my native functions that recieve boolean parameters, will
also be able to recieve boolean objects as well as primitives (without
forcing the user to invoke valueOf() directly). i can't use
JS_ValueToBoolean as i use other JS_ValueTo* to have the same behaviour,
what should i do?

thanks in advance

[Brendan Eich]

Welcome to the world of ECMA.  The ECMA-262 standard, based on JavaScript, never converts an object to a boolean other than true (null converts to false).  The reasoning has to do with the perl-based || and && operators, which may convert their operands multiple times when chained.  Consider:

  o = {valueOf:function(t){return (t == "boolean") ? o.myBoolValue : o},
       myBoolValue:true};
  return (someExpression && o) || someOtherExpression;

in a function.  The return expression evaluates someExpression and, if it converts to true, then evaluates o by calling o.valueOf("boolean"), which returns true, in order to evaluate the first && expression, whose result is o, an object reference.  It then converts o to boolean again in order to decide whether the || result is o or the value of someOtherExpression.

At least one member of the ECMA TC39 working group felt strongly that requiring object-to-boolean conversion to be idempotent and cheap was too much to require of all object classes, and anyway was too different from all other conversion cases, where there is no possibility of an expression converting any of its operands more than once.  I agreed, and this conversion case was dropped from our proposal for the ECMA-262 standard.  It survives in JavaScript1.2, which you can enable in HTML and XUL via (with html: namespace and lower-case names for XUL) <SCRIPT LANGUAGE="JavaScript1.2">, but note well that the 1.2 version of JS has == and != operators that act as === and !== do in ECMA and modern JS.

/be

[itaj sherman]

thanks

form what you wrote, i can now understand the reason for this. but i'm not sure which of the following conclusion i should get to:

1) when a user calls any of my native function that has a boolean parameter, he should be required to invoke valueOf for Boolean objects directly (by himself) if he wants to pass the boolean value and not just true (for the object not being null).

2) i should add (inside my native functions) a conversion for Boolean objects to get the boolean value, so the user can invoke them with Boolean objects just the same way he invokes my native functions with Numbers or Strings (that is, without directly invoking valueOf).

 

the thing is that when i require any other type, the user can pass primitives or objects - even user defined objects written in Javascript will do fine, i just use JS_ValueTo* and it eventually invokes the valueOf() method that could be redefined by the user.

so, for both options, whenever i refer to Boolean object, it is the same question for any other object (user defined classes in JavaScript), that can convert to boolean.

 

if the right option is 2, it means that when i want to get a boolean value i have to use something other than JS_ValueToBoolean. i think this "something" has to invoke the valueOf method eventually - i looked at the API but couldn't find anything like that - should i use JS_CallFunctionName with "valueOf" ?

Brendan Eich <bre...@meer.net> wrote in message news:38D67B33...@meer.net...

[Brendan Eich]

Sorry you're stuck with this ugly need to convert objects to booleans -- just to finish my ECMA story, the reason I caved was because the objection to object-to-boolean turned on the acceptance of Perl-style || and && operators into the ECMA standard.  I felt those were more useful, particularly to Perl-savvy hackers, than valueOf("boolean").  I hope I was right, and people are using, e.g., var x = y || defaultY; and the like, to ensure defined, non-null, not-false, non-zero, non-empty-string initial values in the example.

What you can do from C or C++, rather than add JS_CallFunctionName with "valueOf" as the name, that's cheaper:

    // assume the value to convert is in jsval v
    JSBool b;
    JSVersion oldVersion = JS_SetVersion(cx, JSVERSION_1_1);
    ok = JS_ValueToBoolean(cx, v, &b);
    JS_SetVersion(cx, oldVersion);

JSVERSION_1_1 is cheaper here than JSVERSION_1_2, and just as effective for enabling object-to-boolean conversions, because it doesn't change the meaning of the equality operators.  This sequence will be cheaper still if you apply the attached patch.

/be

[Brendan Eich]

My patch, with a further independent fix, is in bug 32674.

/be