[webkit-dev] incompatibility between DOM spec (IDL) and c-based (gobject) language bindings

Thu Jul 23 05:28:49 PDT 2009

Responding to review comments should be done in the relevant bugzilla  
bug, not on the mailing list. It's ok to post here if you think an  
issue needs wider input from the community, but that doesn't seem to  
be the case with this issue.

Regards,
Maciej

On Jul 23, 2009, at 5:18 AM, Luke Kenneth Casson Leighton wrote:

> starting here:
> https://bugs.webkit.org/show_bug.cgi?id=27435#c3
>
> the issue is raised and noted that the W3C specification has several
> functions with the exact same name and several parameters, and that c
> simply is not equipped to cope with this.
>
> the reason why i'm raising this on webkit-dev is because, contrary to
> belief, the gobject bindings are _not_ limited to the GTK+: the GTK+
> port is just at present the only port which has the necessary
> "linkage" code.  [reason: gobject has nothing to do with gtk.
> #include <gobject.h> does not require #include <gtk.h>].
>
> anyway - the summary conclusion that i came to in dealing with this  
> issue is:
>
> * to provide a "good enough" solution
> * to provide "that which does the job for the most people"
> * to provide "the longest number of arguments and let callers work  
> with that".
>
> just so you know, mozilla _also_ suffers from this exact same problem,
> and the solutions attempted, over several years of development, are...
> a bit of a mess.
>
> http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/ed216e6eb453649a/76829e33f396aade?lnk=gst&q=lkcl#76829e33f396aade
>
> here is where i have provided a "good enough" / "does the job for most
> people" solution, this is in 2DCanvasContext's drawImage function:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=502234
>
> given that the existing XULrunner code _entirely_ cuts everything but
> javascript off from drawImage, absolutely _anything_ is an
> improvement.  the 3-args version is therefore a "good enough"
> compromise.
>
> the gobject bindings do not implement 2D SVG Canvas [yet] - it was
> simply far too much additional work.  the XULrunner example is
> therefore noted as "advance warning" about what kind of grungy
> decisions lie ahead.
>
> xan notes here: https://bugs.webkit.org/show_bug.cgi?id=27435#c4
>
> a recommendation for doing hand-crafted fix-ups.  yes, that's what
> MSHTML does, effectively, because they too are using c (thanks to DCOM
> which in turn relies on MSRPC which is in fact DCE/RPC the underlying
> implementations are all c
> *huge-intake-of-breath-at-overlong-sentence*)
>
> the general policy in DCE/RPC is to simply stack a number on the end
> of the function [and up-rate the IDL revision number, for backwards
> compatibility - a feature not present in webkit].
>
> so, sam, you finally have an explanation as to why adam did this:
> https://bugs.webkit.org/show_bug.cgi?id=16401#c194
>
>>> +sub Uniquify {
>> +    my $name = shift;
>> +    my $avoid = shift;
>> +    if ($name eq $avoid) {
>> +        $name = $name . "2";
>> +    }
>
>  Please explain this.
>
> it looks like it's the beginnings of trying to make auto-generated
> gobject bindings that support the cases where functions in the IDL
> have identical names.   by postfixing a number on them.
>
> now.
>
> from experience with the gobject bindings thanks to pywebkitgtk as
> intermediate bindings which pyjamas-desktop uses, i've found that the
> cases where there are clashes like this are extremely rare, or that by
> having defaults (and passing in 0, False, NULL or '') is perfectly
> sufficient.
>
> passing in 0, False, NULL is what XULrunner's "[optional]" IDL tag is
> all about, and it's a route i'd strongly suggest avoiding.  if
> [optional] is added, then further analysis is made of the argument,
> and, depending on its type, 0, False or NULL is passed in - but that's
> only on _javascript_ bindings: the native c++ access (the xullrunner
> equivalent of linking direct to WebCore) and the language bindings
> are... well... pretty much left to their own devices i.e. stuffed in
> most cases.
>
> so, yes, the number of cases encountered are pretty rare.
>
> * XMLHttpRequest open function takes 5 arguments, 3 of which are  
> optional.
>  it's been discovered that passing in False, '','' as those three  
> arguments
>  "does the job".
>
> * KeyboardEvent initKeyboardEvent function takes... oo... 14 arguments
> in the W3C DOM specification and one extra one in Webkit (contrary to
> the W3C standard), to provide notification when, and discrimination
> of, the Alt-Gr key.  a patch has been submitted which simply
> eliminates on of these functions, for gobject bindings:
>
>   https://bugs.webkit.org/show_bug.cgi?id=27436
>
> if you _don't_ do that, then the gobject bindings will simply fail to
> compile, because you get two c functions with exactly the same name
> [sam: note. answering / explaining
> https://bugs.webkit.org/show_bug.cgi?id=16401#c194 ]
>
> there are a couple of others, but it's no big deal.
>
> overall, then, as noted above, i think you can see that this is a
> hairy / grungy area but that the number of exceptions which need to be
> dealt with are pretty limited, and the evidence and insights in here
> support xan's statement:
> https://bugs.webkit.org/show_bug.cgi?id=27435#c5
>
> and the answer to mark's comment -
> https://bugs.webkit.org/show_bug.cgi?id=27435#c5 is: in the
> auto-generator, _and_ if it's demonstrated and proven that you _need_
> it: if you have a clash, you simply tack on a number.  increment until
> done.
>
> where it is quite often the case that by simply having default values
> and spewing out the longest of the [clashing] functions, it turns out
> to be completely unnecessary to take that approach.
>
> summary, therefore, as mentioned at top of this message: do what's
> "good enough" now, and adapt accordingly, later.
>
> l.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev