[Webkit-unassigned] [Bug 188742] [GLIB] Expose JavaScriptCore options in GLib public API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188742

--- Comment #2 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Adrian Perez from comment #1)
> (In reply to Carlos Garcia Campos from comment #0)
> > I think it would be useful to expose the JSC options in the API. Right now
> > it's possible to change them using the env vars, but it would be better to
> > provide some API. To ensure API/ABI stability we could use a common
> > interface to set the options, that receive the option string identifier and
> > the value, similar to the GtkPrintSettings API, for example. Main problem is
> > that users don't know the options available, so we could provide names for
> > the most important options, like we do in WebKit2 API with editing commands.
> > We could also include API to get information about the options available
> > (name, value type, default value and description). Applications could use
> > that to create command line options to set them, for example.
> > 
> > JSCOptions* jsc_options_get (void); // Get the singleton instance
> > gboolean jsc_options_set_string (JSCOptions* options, const char* option,
> > const char* value);
> > char* jsc_options_get_string (JSCOptions* options, const char* option);
> > gboolean jsc_options_set_int (JSCOptions* options, const char* option, gint
> > value);
> > int jsc_options_get_int (JSCOptions* options, const char* option);
> > ......
> > typedef gboolean (* JSCOptionsFunc) (JSCOptions* options, const char*
> > option, GType type, GValue* default_value, const char* description, gpointer
> > user_data);
> > void jsc_options_foreach (JSCOptions* options, JSCOptionsFunc function,
> > gpointer user_data);
> 
> This being like this, it is like a mini-object system, so I wonder whether it
> would make more sense to make JSCSettings a class which inherits from GObject
> and make each option a property instead:
> 
>  * jsc_options_get_{string,int,bool,…} → g_object_get
>  * jsc_options_set_{string,int,bool,…} → g_object_set
>  * jsc_options_foreach → g_object_class_list_properties
> 
> ...and so on.

That would require to define all the options at compile time. Any option name change or type or removal would break the API.

> > /**
> >  * JSC_OPTION_USE_JIT:
> >  *
> >  * Allows the executable pages to be allocated for JIT and thunks if %TRUE.
> >  * Type: %G_TYPE_BOOLEAN
> >  * Default: %TRUE
> >  */
> > #define JSC_OPTION_USE_JIT "useJIT"
> > 
> > It would be something like that.
> 
> It looks to me that we could even generate the code of such JSCOptions
> class making use of the JSC_OPTIONS() macro to autogenerate the parts of
> the jsc_options_class_init() which install the properties, and have a
> helper function to convert “someOptionName” internal camel-cased option
> names to GObject style snake-case “some-option-name” strings. Note that
> JSC_OPTIONS() even includes descriptions for the options, so those could
> be used when instantiating the GParamSpecs for the properties and then
> the option descriptions will automatically get picked by gtk-doc.
> 
> I think that even if the generated JSCOptions class does not have the
> jsc_options_set_some_option() and jsc_options_get_some_option() methods,
> the GObject properties functions will work well:
> 
>   JSCOptions *options = jsc_options_get ();
>   g_object_set (options, "use-jit", FALSE, NULL);

Yes, without the public getter/setter, it might work.

> If additional type safety there is desired, one can use g_object_setv()
> and g_object_getv(), too.
> 
> Or is there any reason I am missing to not reuse the existing GObject
> properties machinery?

My initial idea was to use GObject properties indeed, similar to WebKitSettings. API stability was my main concern.

> Also: Maybe I would call this “JSCSettings”, to keep the name consist
> with “WebKitSettings”.

Also thought about it, but I'm not sure. JSC options are not like WebKit settings, so we don't really need to be consistent. In the case of JSC, options are normally set at the very beginning of the program execution and never changed again.

-- 
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/20180820/6cfa6f7e/attachment.html>