[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
> 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
+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
- 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