<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi folks.<div class=""><br class=""></div><div class="">You may have noticed the substantial improvements we’ve made to our WebIDL support over the last year.<br class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">The first step in this direction is in <<a href="https://bugs.webkit.org/show_bug.cgi?id=161295" class="">https://bugs.webkit.org/show_bug.cgi?id=161295</a>>.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I see a few different options, maybe not all real practical ones:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Are there other practical options?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">— Darin</div></div></body></html>