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

Luke Kenneth Casson Leighton luke.leighton at googlemail.com
Thu Jul 23 05:18:50 PDT 2009


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.


More information about the webkit-dev mailing list