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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Feb 13 07:58:57 PST 2009


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





------- Comment #171 from adam at yorba.org  2009-02-13 07:58 PDT -------
Thanks for the detailed feedback on the generated code.  We will address all
issues you've pointed out in the next patch iteration.  We'll also ensure that
srcdir != builddir builds work; unfortunately we didn't get around to testing
these last time around.

Regarding the naming prefix, it seems the clear consensus is to use something
starting with WebKit.  I don't think we should use WebKitDOM since it's been
pointed out that the all-caps acronym will confuse the Python bindings
generator.  There are really three possibilities:

1. WebKit: WebKitDOMObject, WebKitDOMWindow, WebKitElement, WebKitHTMLElement,
and so on.

2. WebKitDom, strictly: WebKitDomDOMObject, WebKitDomDOMWindow,
WebKitDomElement, WebKitDomHTMLElement, and so on.

3. WebKitDom, but removing the "DOM" where it's redundant: WebKitDomObject,
WebKitDomWindow, WebKitDomElement, WebKitDomHTMLElement, etc.  (There are a
total of 7 interfaces where the name DOM would get spliced out.)

It's been pointed out by me and others that an advantage of WebKitDom is that
all DOM classes would get grouped together.  On the other hand, there are
presently only 10 non-DOM WebKit classes, and all but one of these begin with
WebKitWeb: we have WebKitWebFrame, WebKitWebView and so on.  The sole exception
is WebKitNetworkRequest.  So even if we choose (1) above, all DOM classes will
still essentially appear together: they will consist of all classes in a long
list save the few that begin with WebKitWeb and one other exception.

Regarding implementation, (1) or (2) are easy.  (3) is slightly tricky, but
probably doable.  Due to the limitations of GNU Make's implicit rules, we'd
probably have to let the Makefile generate source/object files with full names
such as WebKitDomDOMObject.cpp, then have additional rules that copy or rename
these files to have the names we want such as WebKitDomObject.cpp.  The Perl
script would of course also have to know how to splice these names.  But I
think we can take this on if the consensus is that it's what we want.


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