[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=16401


soto at informatik.uni-kl.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24395|0                           |1
        is obsolete|                            |




------- Comment #96 from soto at informatik.uni-kl.de  2008-11-30 15:30 PDT -------
Created an attachment (id=25618)
 --> (https://bugs.webkit.org/attachment.cgi?id=25618&action=view)
DOM patch updated to version 38852

So, as I said, my time is quite limited these days, but I managed to make some
progress with the patch. This version is not yet ready for review, but I wanted
to share it because there are some issues I'd like to discuss.

First of all, what I did so far: With the previous patch, three memory blocks
were being allocated to wrap a single core DOM object: the *public* structure
for the wrapping GObject, the *private* structure for the wrapping GObject, and
an additional C++ wrapper object. I got rid of the additional C++ wrappers
altogether, which means that the private GObject structures now point directly
to the core objects. I removed all classes, both generated and manually
written, related to these wrapper objects. This not only helps with efficiency,
but makes the patch easier to read, because the naming scheme used for the C++
wrappers made them very easy to confuse with the corresponding GObject classes.
Additionally, while doing this, I refactored the code in many places to be more
consistent, both in naming and behavior, with the rest of WebKitGtk.

The first question I have is related to the GObject private structures. At this
time, they contain only a pointer to the wrapped core object. We could also get
rid of them and put this pointer directly in the main (public) wrapper GObject.
The changes necessary for doing this are trivial now, and this would let us
with just one allocated block per wrapped object, which would be valuable,
since DOM wrappers may happen to be created in large quantities. I don't know
however, what effect this may have for ABI compatibility in the future.

I also started checking the use of RefPtr and friends in the patch, and I
currently have an issue I don't know how to solve. In file GDOMBinding.cpp, a
number of functions called toGDOM are defined that are intended to wrap core
DOM objects into GObjects. Since these function actually take ownership of the
references they receive, they should use PassRefPtr's as parameters. Problem
is, when I change the parameters, which currently are raw pointers, to
PassRefPtr, the compiler is not able to resolve the calls any more, complaining
that they are ambiguous. What should I do in this case? Giving the functions
different names based on the argument types doesn't look like an option,
because deciding which one to call (this is mainly done by generated code) is
not trivial. Any suggestions here would be greatly appreciated.

Finally, I would like to rename all files, manual and generated, according to
the conventions used by the rest of WebKitGtk. This is no problem, but I'm
wondering about the GDOM prefix. I see no reason to have a different prefix for
the DOM related objects. They belong to WebKitGTK as much as anything else,
and, in my opinion, should use the same naming convention. Would people agree
with this? Should I just change everything to use the WebKit (or webkit_
dpending on the case) prefix?


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.