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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev