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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 11 01:20:00 PST 2009


xan.lopez at gmail.com changed:

           What    |Removed                     |Added
                 CC|                            |xan.lopez at gmail.com

------- Comment #130 from xan.lopez at gmail.com  2009-02-11 01:20 PDT -------
(In reply to comment #128)

Hi, thanks for picking up this!

> == open questions ==
> Here are design decisions that potentially remain open along with their current
> status. �We're happy to change any of these in the code to satisfy the
> consensus of the WebKit team.
> 1. How should GObject DOM classes be named? �To represent the DOM interface
> called Element, we could use any of the following: �GdomElement (the current
> choice); GDOMElement; WebKitElement; WebKitDOMElement.
> We don't have a strong opinion here. �It's slightly unusual for a single GTK
> package to contain classes with two different prefixes, and so if we use the
> Gdom or GDOM prefix we'll need to play some tricks in order to autogenerate
> Vala bindings for the webkit-1.0 package, which will contain some classes
> prefixed with WebKit (e.g. WebKitWebFrame) and others prefixed with Gdom/GDOM.
> �(We've actually done this, and can share our Vala bindings generator script if
> you like.)
> If we use names such as�WebKitElement or WebKitDOMElement�then Vala bindings
> should be automatic. �If we use WebKitElement without the word DOM, then API
> documentation which shows a sorted list of classes will show DOM classes
> interspersed with other WebKit classes; this might be confusing. �On the other
> hand, the WebKitDOM prefix will lead to long names such as
> WebKitDOMHTMLBlockquoteElement.
> If we use either the Gdom, GDOM or WebKitDOM prefix we might want to remove
> duplicate occurrences of the word DOM; for example, we could replace
> GdomDOMObject with GdomObject. �We have not done this at this point.

When this has come up before I've said that I prefer consistency and making
life easier for bindings in general, even if the price to pay is longer type
names for C hackers. IMHO C/GObject hackers are already used to boilerplate and
complexity that is only there for the benefit of the bindings, and they usually
solve this with macros and code completion :)

> 2. Should a DOM attribute be exposed both via getter/setter methods and via a
> property, or only via getter/setter methods? �As mentioned above, we currently
> have both getters/setters and properties but are willing to take the property
> code away if desired.

I think we should have both. AFAIK explicit getter/setter methods predate the
property system, and are only retained for compatibility and performance
reasons, but I'm pretty sure many bindings will construct their getter/setters
from the property directly, maybe overriding them with the direct access
functions IF they exist (this is what the Java bindings do IIRC), or providing
both the same way C does. Also properties have other benefits, like notify
functions, mass set/get, etc.

> 3. How does a string returned by a DOM function get freed? �Currently the
> caller is responsible for freeing. �In comment 28 Alp suggested other possible
> mechanisms such as some sort of garbage collection. �We believe that the
> existing caller-frees policy is the way to go; it is the usual mechanism in
> GObject classes and will play well with higher-level language bindings.

Completely agree. Anything else would probably be a nightmare for bindings.

> ===
> We're looking forward to having these bindings in WebKit!  Please let me know
> if there's anything more we can do to help out.

Some small nitpicks from the patch, style issues:

You are using NULL all over the place,  I think '0' is preferred for stuff that
goes into WebCore/ (we use, or try to use, NULL for C-ish files that go into
WebKit/gtk/ though...)

+gpointer GDOMObjectCache::getDOMObject(void* objectHandle)
+    gpointer ret = domObjects().get(objectHandle);
+    return ret;

No need for the variable.

+gpointer toGDOM(HTMLCollection* collection)
+    if (!collection)
+        return NULL;


Is it a valid usage of the function to pass NULL? If not you should use
g_return_val_if_fail() IMHO.

- The g_dom_string_convert methods seems pretty generic, maybe you could change
the gdom_ prefix for something else?

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.

More information about the webkit-unassigned mailing list