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

[bugzilla-daemon at webkit.org]

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


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.