[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 #5 from Adrian Perez <aperez at igalia.com> ---
(In reply to Carlos Garcia Campos from comment #4)
> (In reply to Adrian Perez from comment #3)
> > (In reply to Carlos Garcia Campos from comment #2)
> > > (In reply to Adrian Perez from comment #1)
> > > > (In reply to Carlos Garcia Campos from comment #0)
> >
> > [...]
> > 
> > So no matter which of both approaches is implemented, the API can break
> > between releases. The only way of preventing that in both cases is avoiding
> > to merge JSC patches in stable release branches that include changes to the
> > JSC options — and allowing changes in between major releases.
> 
> But in the case of not autogenerated code, we would only provide macros for
> a few common options, that are more unlikely to change. We can deal with
> changes in any case, we have experience with that when the DOM bindings were
> autogenerated, and that's the main reason why I want to avoid generated code
> here :-) I don't know how we could deal with range options using properties,
> unless we consider them a string of the form begin:end and parse it. With
> explicit API we could simply add get/set_range (options, begin, end);

Fair enough! Let's not autogenerate the code then.

> > > > > /**
> > > > >  * 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.
> > 
> > As I outlined above, the approach you suggested has exactly the same
> > potential API stability issues as using GObject properties.
> 
> Not exactly the same, an option rename wouldn't be a problem without
> auto-generated properties. And again, the amount of options with a name in
> the API would be low.

But the API would still allow setting the options for which we do not
add a “#define JSC_OPTION_FOO”, right? I would rather not allow that
behaviour.

> > Therefore
> > I would go with the solution that feels more natural in a GLib/GObject
> > API and use object properties.
> 
> I'm not sure an object with no public API but a getter for the global
> instance is "natural" :-) I know GObject properties are also public API, but
> still.

Now that you have convinced me about *not* autogenerating code,
I guess it's not much use exposing the properties either ;-)

-- 
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/20180824/1ab4023c/attachment.html>