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

[bugzilla-daemon at webkit.org]

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





------- Comment #106 from lkcl at lkcl.net  2008-12-02 02:38 PDT -------
(In reply to comment #105)
> >  the pointer is stored in a RefPtr<WebCore::Element> in the "internal"
> >  c++ class that has GDOMObject as its base: a private member called m_impl.
> 
> The JavaScript bindings do not create a local PassRefPtr to pass in to toJS, as
> the code quoted above does.

 well... i didn't want to admit this, because i really _do_ want to encourage
 martin's involvement, but as things stand i've not been able to merge in
 your contributions, martin, because, due to the size of the patch, finding
 them is too time-consuming.

 so, i'm still using  http://github.com/lkcl/webkit/tree/16401.master

 the reason i mention that, mark, is because i'm still working with
 toGDOM(WebCore::{insertclassname}*) - as is done in the JSBindings.

> What you describe relates to how the wrapper holds the reference to the wrapped
> object.  Holding it as a RefPtr is indeed what the JavaScript bindings do, and
> what most (all?) bindings layers should do.  The Objective-C bindings don't do
> this for historical reasons.

 ok - well, i've removed the manual calls to ref() and unref() and there
 doesn't appear to be any collateral damage.


> >  perhaps the solution to satisfy mark's concerns is as simple a matter of
> >  removing the calls to ref() and deref() - i'll see what effect that has.
> 
> Using ref() and deref() manually without a specific need to do so is a good
> indication that reference counting is being handled incorrectly.  The latest
> iteration of the patch still appears to have problems in this area.

 i had corrected the ref and unrefs to match up - however, given that
 the gdom private c++ objects (all those that derive from GDOMObject)
 all have a RefPtr to the underlying webcore c++ object, it looks like
 the ref() and unref() calls are completely unnecessary.

 and your descriptions of the way things work - and of the historical
 objc workings - would seem to bear that out.


> One part of the patch doesn't quite make sense to me:  what is the relationship
> between the generated "_${className}Private" structures and
> _GdomDOMObjectPrivate?  They both contain members named coreObject, but only
> the former uses a RefPtr for this purpose.  This seems as though it could lead
> to confusion.

 lemme take a look and get back to you.

 thx.


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