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

[bugzilla-daemon at webkit.org]

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





------- Comment #31 from lkcl at lkcl.net  2008-09-13 08:57 PDT -------
> Also, the GDOM* C++ classes (and PrivateInt*.h) don't seem 
> to serve much of a purpose at first glance unless I missed something.

> If you look at WebCore/bindings/objc/DOM.mm you can see that the ObjC binding
> happily creates platform objects directly without this indirection, and it
> should be possible to construct the GObject wrappers directly in a similar
> fashion.

alp, imagine i'm sitting in front of you, so you can see how wide
my eyes are, with this big comic 1000-yard stare on my face like the
top of my head is about to come off and bits of brain go into the
sky and rain down over a 50 metre radius.

the speed and intensity with which i got this stuff going was scarily
quick.  much of the decisions were made... how-to-say... on auto-pilot.
to do the GdomDOMObject stuff i cut/paste large sections of JS* code,
and followed whatever styling - from both the ObjC _and_ the JS stuff -
worked best.

the Gdom* classes i had to create, following the exact same reasoning
from the JS classes.  it was a looong ten days ago.... oh, christ, i
remember now.

it's coming back... yes.  the hash-map thing.  references.  the Gdom*
classes store a ref.  this is absolutely essential.  and, you need
a virtual base class in the lowest-level thing - GdomDOMObject - to
be able to call in to find out the GOBJECT_TYPE.

otherwise, you end up creating the wrong type of "wrapper".

that's the whole point of the GDOM*ElementFactory thing - and the
whole point of the JS*ElementFactory - exactly the same issue.

what happens otherwise is that if you call e.g. gdom_create_text_node()
and add it to the DOM with gdom_node_add_child(parent, textnode), and
you then get it back with gdom_document_get_element_by_id(), if you
_don't_ have the DOMObjectCache that GdomDOMObject refers to, whilst
gdom_create_text_node() creates a GDOM_TEXT_NODE,
gdom_document_get_element_by_id() returns .... a GDOM_NODE!!!

because that's the return result - a base class - that 
gdom_document_get_element_by_id() returns!

which of course is completely unacceptable - and, worse, you end
up with _two_ different types of GObjects - one a GDOM_NODE
and another a GDOM_TEXT_NODE - pointing to exactly the same
underlying c++ object!

so, i had to cut/paste the JS*ElementFactory code, pretty much verbatim.

so, the hash map avoids the problem of returning different
glib objects that represent the same c++ object; the pure
virtual function GDOMObject::get_gobj_type() makes sure that
you construct the _correct_ type of glib object even when
you're down in things like gdom_document_get_element_by_id();
the toGDOM functions actually do the heavy-lifting in that
regard (copying cut/paste the style of all the toJS functions);
it's all utterly hair-raising and i'm now going downstairs to
watch some mindless tv to let my brain cool down :)


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