Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Let JSVAL_IS_OBJECT only check for objects, not null
38 views
Skip to first unread message
Tom Schuster
May 5, 2012, 1:50:24 PM5/5/12
to JS list
Hello!
I was looking into removing any use of JSVAL_IS_OBJECT from the
mozilla codebase. Turns out that this function would really win in
usefulness if it wouldn't return true for |null|. So I am proposing to
do that, let JSVAL_IS_OBJECT do what it says, return true _only_ for
JSObjects. Furthermore I propose that JSVAL_TO_OBJECT also only
returns objects and not null, thus probably getting rid of a lot of
null checks.
This way we could also get rid of the terrible !JSVAL_IS_PRIMITIVE
anti-pattern. We use these functions quite a few times and I would
think embedders do that too.
So my question is how useful feasible is this?
~Tom
I was looking into removing any use of JSVAL_IS_OBJECT from the
mozilla codebase. Turns out that this function would really win in
usefulness if it wouldn't return true for |null|. So I am proposing to
do that, let JSVAL_IS_OBJECT do what it says, return true _only_ for
JSObjects. Furthermore I propose that JSVAL_TO_OBJECT also only
returns objects and not null, thus probably getting rid of a lot of
null checks.
This way we could also get rid of the terrible !JSVAL_IS_PRIMITIVE
anti-pattern. We use these functions quite a few times and I would
think embedders do that too.
So my question is how useful feasible is this?
~Tom
Blake Kaplan
May 9, 2012, 9:36:32 AM5/9/12
to dev-tech-...@lists.mozilla.org
On 05/05/2012 07:50 PM, Tom Schuster wrote:
> So my question is how useful feasible is this?
It seems to me like this is basically going to happen for "free" with
> So my question is how useful feasible is this?
the introduction of JS::Value (which already makes this distinction).
There are places in our tree right now where we depend on the current
behavior and a change like this would introduce very subtle bugs.
ECMAScript 5 didn't make the typeof null -> "null" change for the same
reason.
-Blake
Tom Schuster
May 9, 2012, 2:10:15 PM5/9/12
to Blake Kaplan, dev-tech-...@lists.mozilla.org
On Wed, May 9, 2012 at 3:36 PM, Blake Kaplan <mrb...@mozilla.com> wrote:
> On 05/05/2012 07:50 PM, Tom Schuster wrote:
>> So my question is how useful feasible is this?
>
> It seems to me like this is basically going to happen for "free" with
> the introduction of JS::Value (which already makes this distinction).
Probably not for free, because this is serious work to port over. And
> On 05/05/2012 07:50 PM, Tom Schuster wrote:
>> So my question is how useful feasible is this?
>
> It seems to me like this is basically going to happen for "free" with
> the introduction of JS::Value (which already makes this distinction).
some code might only be compilable in C mode?
> There are places in our tree right now where we depend on the current
> behavior and a change like this would introduce very subtle bugs.
Not a big deal, I already fixed this stuff in our tree. I was more
> behavior and a change like this would introduce very subtle bugs.
interested in how this would affect other embedders.
> ECMAScript 5 didn't make the typeof null -> "null" change for the same
> reason.
>
> -Blake
> _______________________________________________
> reason.
>
> -Blake
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
0 new messages