Porting Guide For Embedders: JS38 -> JS45

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Porting Guide For Embedders: JS38 -> JS45

Kent Williams
I acknowledge that I got into this perhaps too early in the process with
respect to the progress on documenting the new release.  But there is a
compelling reason for going to JS45 -- the API is almost completely C++,
removing much of the clumsiness the C-style holdovers that remained in JS38.

I'm starting from the github rep
https://github.com/mozilla/gecko-dev.git and building the esr45 branch.


Here is my list of changes. It isn't comprehensive, because we don't get
that advanced in how we deal with embedding, but it's a good start.

 1. jsval typedef is gone, use JS::Value instead.
 2. OBJECT_TO_JSVAL (and STRING_TO_JSVAL, INT32_TO_JSVAL etc) are gone,
    use JS::Value::setObject, JS::Value::setString etc
 3. JS_NewDateObjectMsec is gone. Replace with JS::NewDateObject(cx,
    JS::TimeClip(unixEpochTime))
    Requires #include <js/Date.h>.
 4. X_TO_JSVAL gone, replace with JS::XValue, e.g. DOUBLE_TO_JSVAL(val)
    -> JS::DoubleValue(val)
 5. JS_Init declaration moved to <js/Initialization.h>
 6. JS::AutoIdArray replaced with JS::Rooted<JS::IdVector>
    This means going from this idiom

    JS::AutoIdArray jsattrs(cx,JS_Enumerate(cx, attrobj));

    To this

    JS::Rooted<JS::IdVector> attrs(cx,JS::IdVector(cx));
    JS_Enumerate(cx, attrobj, &attrs);

 7. JS_IsArrayObject acquired a new parameter, isArray. This is true if
    the object is an ArrayObject, but false when passed a proxy, or a
    revoked proxy.  I haven't looked at the source but it would be more
    graceful if the prototype was

    bool JS_IsArrayObject(JSContext *cx, JS::HandleValue value, bool *isArray = nullptr);

    So that if you are sure that A) it is always going to be an array or
    B) you don't care, you don't have to declare a boolean variable you
    never test.
 8. JS_NewObject lost it's 3rd parameter, a prototype object. If you
    want to give a prototype, use JS_NewObjectWithGivenProto
 9. JS::NullPtr is gone. Replace with C++11 nullptr.
10. libjs_static.a gets built in dist/js/src where before it was in
    dist/lib -- this feels like a bug.


_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting Guide For Embedders: JS38 -> JS45

Boris Zbarsky
On 3/18/16 12:52 PM, Kent Williams wrote:

> 7. JS_IsArrayObject acquired a new parameter, isArray. This is true if
>     the object is an ArrayObject, but false when passed a proxy, or a
>     revoked proxy.  I haven't looked at the source but it would be more
>     graceful if the prototype was
>
>     bool JS_IsArrayObject(JSContext *cx, JS::HandleValue value, bool
> *isArray = nullptr);
>
>     So that if you are sure that A) it is always going to be an array or
>     B) you don't care, you don't have to declare a boolean variable you
>     never test.

I think you're misreading the new API.

The outparam is the "is this an array?" value.  The return value is true
if the test succeeded (in the sense of being able to tell whether this
is an array), false if an exception was thrown.

If you're not testing the outparam, you're doing it wrong.  ;)

-Boris
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting Guide For Embedders: JS38 -> JS45

Jason Orendorff-2
In reply to this post by Kent Williams
On Fri, Mar 18, 2016 at 11:52 AM, Kent Williams <[hidden email]>
wrote:

> Here is my list of changes. It isn't comprehensive, because we don't get
> that advanced in how we deal with embedding, but it's a good start.
>

Thanks for sharing this, Kent.


> 7. JS_IsArrayObject acquired a new parameter, isArray.


Boris is right, this is the out-parameter.

10. libjs_static.a gets built in dist/js/src where before it was in
>    dist/lib -- this feels like a bug.
>

Thanks for reporting this. Please file a bug in bugzilla and Cc: me.
Mozilla's build system team occasionally breaks stuff because there are no
automated tests continually checking that every part of the standalone
build works as expected. Can't blame them. If nobody files bugs, nobody
knows it's broken.

-j
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine