Hi folks.
You may have noticed the substantial improvements we’ve made to our WebIDL
support over the last year.
Also, the last few days I’ve been working on one small exciting improvement to
our JavaScript bindings. We can express exceptions as a special return value
inside the DOM implementations, ExceptionOr<ReturnType>, instead of using an
ExceptionCode& out argument. This has many benefits; one of them is that we
don’t need the [RaisesException] family of extended attributes to generate
JavaScript bindings. Instead the bindings use C++ templates to generate
exception-propagating code when needed based on function return types without
having to specify anything in the IDL.
The first step in this direction is in
<https://bugs.webkit.org/show_bug.cgi?id=161295
<https://bugs.webkit.org/show_bug.cgi?id=161295>>.
For Objective-C bindings, our approach is now that instead of trying to
implement WebIDL features, we instead hand maintain a legacy set of bindings as
we change the underlying DOM implementation. This works because we decided to
“freeze” the bindings and no longer intend to automatically generate them or
have them automatically track additions to the web platform. For WebKit at
Apple, we consider the Objective-C bindings a part of the legacy WebKit, and
for the modern WebKit API (WebKit2) we use different approaches inside injected
bundles, such as dynamically bridging from Swift and Objective-C to JavaScript
rather statically bridging to the DOM. Stability is more important than
features for our Objective-C bindings; they are there largely for compatibility
rather than being our favorite forward-looking API for manipulating webpage
content.
For gobject bindings, I have not yet found a simple solution to moving forward.
For most WebIDL features we have simply been coding the gobject bindings
generator so it does not try to generate code for functions that make use of
them. For this new exception approach we have another challenge: Unlike the
Objective-C bindings or the JavaScript bindings, the signature of the gobject
binding functions is different when an exception is involved, because there is
a GError** out argument for each of them. So unlike JavaScript or Objective-C,
both of which use an exception system for the bindings which does not affect
function signatures, the gobject bindings generator today depends on exception
extended attributes to determine what the interface is to each binding
function. This is a problem I must solve to move forward with the new exception
model for our DOM and WebIDL without breaking gobject bindings.
I see a few different options, maybe not all real practical ones:
Option 1) Freeze gobject bindings as we did the Objective-C ones; stop auto
generating them. Add new bindings by hand as desired and needed. This has major
benefit for people working on WebIDL features for the JavaScript bindings; we
have a lot of work to do on those and we are not easily able to make the
gobject bindings come along. There are all sorts of new WebIDL features that we
cannot easily implement for gobject without considerable effort, such as enum
and union types, various types of overloading and default argument values,
setlike, the list goes on and on and this has been going on for months at least
already. There’s a good reason we did this “freezing” for Objective-C and it
seems likely to be worthwhile for gobject too. This will also let us get rid of
the 88 places in the IDL files where we have gobject-binding-specific #if
statements, many of which were originally added for Objective-C and probably
have not all been carefully audited.
Option 2) Express the list of which functions have a GError** out argument as
an explicit list of function names inside the gobject bindings generator and
generate code accordingly. This is not all that farfetched given we already
have .symbols files to help keep the set of gobject bindings functions stay
stable, and there is already a list inside the bindings generator of functions
that used to raise exceptions and therefore have a GError** out argument that
is never used, showing that this issue is not a new one. Compared to (1) this
is just a stopgap measure. It can keep existing functions working, but does not
give us a clear path for what to do as we add more and more DOM APIs that don’t
fit in with what the gobject binding code generator can do.
Option 3) Keep the extended attributes telling whether something raises
exceptions in the IDL files as gobject-specific attributes that are ignored by
the JavaScript bindings.
Are there other practical options?
I strongly prefer option 1, and I would like to hear from the people who are
working to make the gobject bindings work well to get an idea of how they feel
about this and how they’d like to proceed, before I decide what to do.
— Darin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
