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

[bugzilla-daemon at webkit.org]

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





------- Comment #110 from lkcl at lkcl.net  2008-12-02 04:11 PDT -------
(In reply to comment #108)
> (In reply to comment #103)
> >  that's an absolutely necessary wrapper object that contains the
> >  pure virtual function getGObjType(), and is tied in to the
> >  DOM Object cache in GDOMBinding.cpp
> > 
> >  without that pure virtual function, the whole system collapses as
> >  you cannot correctly typecast an object back to its proper c++
> >  core object.
> 
> Let me address only this point because I have to leave in a few minutes.

 ok - well, these archives are forever - they're not going away, they'll
 be here when you're back :)

> I read
> your comments in the code about the "absolutely necessary getGObjType() virtual
> method", and spent quite some time checking all code paths were it was
> involved. It turns out that this method returns exactly the same GObject type
> that is stored in the wrapping GObject.

 ah... ah... um... if it _exists_ yet.

> After checking the code quite
> thoroughly, I found that, in practice, all getGObjType() was being used for,
> was to carry information from the top of the toGDOM functions to the bottom of
> those same functions. I changed the toGDOM functions to wrap the core objects
> into GObjects right from the start, and so I could get rid of getGObjType()
> alltogether.

 if that works, in both the usage cases, i'll genuinely be dead impressed.

 it's been so damn long i wish this hadn't been left for so damn long,
 because i'm struggling to remember the two usage cases.

 the first is clear: there are, what... 150 or more "new" object
 instantiations through GDOMBinding.cpp and from there in many
 cases to GDOMHTMLElementWrapperFactory.cpp (all of which you've
 replaced with wrapXxxxXxxx functions).


 the code path that particularly has me concerned is the one where the object
 is NOT in the cache, and DOM.getElementById("..."),
 DOM.getElementsByTagName(...) etc. are used.

 the WebCore c++ functions return a Node*.  the object is _actually_ an
 (e.g.) HTMLDivElement*, and GDOMBindings.cpp goes to a hell of a lot of
 switch statement trouble to make damn sure that the right gobject is
 created.

 you know what?

 i think you're right - i think it's those switch statements that do the
 correct work.

 _great_.

> Just look at the relevant portions (you surely know were to find them, no need
> to compare) or, even better, run it.

 *freaks out slightly* :)

> It runs here for sure, so certainly
> getGObjType() was not so absolutely necessary.

 i'll find out soon enough and get back to you.


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