[Webkit-unassigned] [Bug 164061] [GTK][WPE] Initial implementation of JavaScriptCore glib bindings

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Feb 22 06:46:14 PST 2018


Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
 Attachment #295368|0                           |1
        is obsolete|                            |
 Attachment #295368|commit-queue?               |
              Flags|                            |

--- Comment #17 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Created attachment 334449

  --> https://bugs.webkit.org/attachment.cgi?id=334449&action=review

WIP patch

I've started to work on this again. This is a WIP patch of what I have so far. I changed my mind with regard to several decisions we made in the past:

 - Use a single JSCValue class: the hierarchy we had didn't make sense in the end. Any value can be converted to other value types, it's perfectly valid to do something like 

value = jsc_value_new_string(context, "25");
g_assert_cmpint(jsc_value_to_int32(value), ==, 25);

And it's also true that an array is also an object so:

value = jsc_value_new_array(context, G_TYPE_NONE);

So, I decided to leave a single JSCValue (only using a dedicated type for exceptions even when they are values too, just for convenience) with is() and to() methods. The API that is expected to be called on a specific value type uses the pattern jsc_value_foo_do_whatever, for example jsc_value_object_set_property().

 - No floating references. For now JSCValue is a normal GObject and we return transfer full and never adopt parameters. We can change this in the future to adopt in some cases to be able to do things like:

jsc_value_object_set_property(object, "foo", jsc_value_new_number(context, 25));

This is indeed convenient, but makes other cases inconvenient, so we'll see.

 - Values are cached by the context, but not owned, they are removed from the cache when destroyed.

These are the main differences. I've added API to support most of the types and convenient methods to handle them. There's also API to evaluate scripts, get/set values to global object and to create new classes implemented by a C object/struct. There are still a lot of things to do:

 - Documentation.
 - Introspection friendly, I'm using varargs in several places without the alternative for bindings.
 - Make it installable.
 - Add support for == and ===
 - Add support for dates
 - Add support for more glib types (strv, GHashTable, etc.).
 - Add convenient API on top of current JSCClass to easily export GObjects.
 - And more things I don't remember now.

Then, on the WebKit side:

 - We need to deprecate all WebKit API using the JSC C API types and provide alternatives using the new glib API
 - We could also deprecate the DOM bindings and add a bridge API between DOM and JSC.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180222/4cf24379/attachment.html>

More information about the webkit-unassigned mailing list