<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=""><div><blockquote type="cite" class=""><div class="">On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos <<a href="mailto:carlosgc@webkit.org" class="">carlosgc@webkit.org</a>> wrote:</div></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Does that mean than from the WebIDL point of view all methods can now</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">raise a exception? If don't tell the code generator that a method can</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">raise a exception, we assume all could return a Exception?</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div>Correct.</div><div><br class=""></div><div>Once the transition is done, the IDL will no longer indicate which functions can raise exceptions; the return types of C++ member functions will, instead. During the transition, exceptions can be indicated in either way.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">It actually depends on whether this is an exception or not.</span></div></blockquote><div><br class=""></div><div>I’m not sure exactly what you mean. But I expect us to keep driving JavaScript DOM bindings forward in lots of ways. Here are a few:</div><div><br class=""></div><div>- We will add support for more WebIDL features. There are many still to go. In some cases that means removing code that is currently in the DOM that is doing part of the bindings work and using WebIDL to implement this things. For example, translation of strings into enum values. WebIDL includes a specification of how all these features are reflected in JavaScript, but for non-JavaScript bindings we have to define how to reflect each feature.</div><div><br class=""></div><div>- We will add better exception messages, which means DOM code has to provide more than an exception code.</div><div><br class=""></div><div>- We will update bindings with changes to move the web platform forward, with JavaScript-specific strategies for backward compatibility that won’t necessarily work for other languages such as Objective-C. For example, the latest specifications turn DOMImplementation.hasFeature into a function that ignores its arguments and always returns true. That’s easy to implement with WebIDL for JavaScript, but for GObject and Objective-C we need code somewhere that remembers what the old argument list was.</div><div><br class=""></div><div>- We will update bindings with changes that have minimal observable effect in the JavaScript type system but have effects on types of arguments or return values in GObject bindings, such as making a return type more specific (Attr instead of Node) or changing which numeric type is used.</div><div><br class=""></div><div>- We will move things currently done in the DOM itself into the bindings.</div><div><br class=""></div><div>- We would like to change the bindings generation scripts to run more quickly and so that fewer run when a given IDL source file is changed.</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">If you </span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">really think that build is going to be broken often because of things </span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">very difficult to do in the GObject bindings, then we should indeed </span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">find a more general solution. Otherwise I prefer to solve this problem </span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">now, and keep the existing way of generating the bindings. We can add a </span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">rule that you can break the GObject DOM bindings build, to not block </span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">your work, and I'll try to fix it asap as we currently do with WebKit2.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">Something like this might work. But coping with these changes is going to be challenging.</div><div class=""><br class=""></div><div class="">I expect we are going to continue to run into many things we want to do for JavaScript that are difficult to do in the GObject bindings. It’s taken many people hundreds of hours already to add these various WebIDL features for the JavaScript bindings, and each one involved changing both the bindings and the underlying DOM implementation.</div><div class=""><br class=""></div><div class="">I think the 88 already existing #if statements in the IDL are one indication that the IDL-based code generation strategy isn’t working very well; *many* features that are simply not supported outside the JavaScript code generator because they use one of the newer IDL features are another.</div><div class=""><br class=""></div><div class="">If you read the latest WebIDL draft <<a href="https://heycam.github.io/webidl/" class="">https://heycam.github.io/webidl/</a>> you will see lots of features that are tricky to deal with—dictionary types, enumeration types, callback function types, promise types, union types, regular expressions, frozen arrays, stringifiers, serializers, indexed properties, named properties, overloading, map like, setlike—the only reason this is not a crisis is that many web APIs are old and so not built on any of these new concepts. Over time, critical features are being built on them.</div><div class=""><br class=""></div><div class="">I am OK with the “it is OK to break the GObject bindings build” strategy, I guess, but are you sure you are OK with that?</div><div class=""><br class=""></div><div class="">— Darin</div></body></html>