Jim Chen <mailto:[email protected]>
2014 May 23 at 11:23
I think a good compromise between correctness and practicality would be
to treat null and undefined as equivalent in NativeJSObject. If people
are expecting and using them as equivalents, we can just treat them as
such.
JS code often treats them as equivalent, since they both evaluate to
boolean false in a logical expression. But some of the JS code in our
tree distinguishes between them, using the "in" operator (or comparing
the property's value to the undefined value) to determine if a JS object
has a property.
This is really simple to do (one-line patch), and will make opt*
return the fallback value for any null properties.
That seems reasonable for the opt* methods, which optimize for convenience.
It will also let you
use NativeJSObject.has() in place of isNull().
I would maintain the current behavior of these methods, so code that
cares can distinguish between null and undefined.
Unlike opt*, the usage of these methods is reasonably low, at 37 and 20
lines, respectively, via a primitive grep through mobile/android/base.
So they could be audited in a reasonable amount of time to ensure their
behavior is what their callers expect.
-myk
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
