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

[bugzilla-daemon at webkit.org]

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





------- Comment #102 from mrowe at apple.com  2008-12-01 16:05 PDT -------
(In reply to comment #101)
> DerivedSources/gdom/GdomAttr.cpp: In function ‘void
> gdom_attr__get_property_fn(GObject*, guint, GValue*, GParamSpec*)’:
> DerivedSources/gdom/GdomAttr.cpp:198: error: call of overloaded
> ‘toGDOM(WebCore::Element*)’ is ambiguous
> ./WebCore/bindings/gdom/GDOMBinding.h:61: note: candidates are: void*
> WebKit::toGDOM(WTF::PassRefPtr<WebCore::Element>)
> ./WebCore/bindings/gdom/GDOMBinding.h:63: note:                 void*
> WebKit::toGDOM(WTF::PassRefPtr<WebCore::EventTarget>)
> ./WebCore/bindings/gdom/GDOMBinding.h:64: note:                 void*
> WebKit::toGDOM(WTF::PassRefPtr<WebCore::EventTargetNode>)
> ./WebCore/bindings/gdom/GDOMBinding.h:66: note:                 void*
> WebKit::toGDOM(WTF::PassRefPtr<WebCore::Node>)

Ok, I can see why this would be ambiguous.  Element* is implicitly convertible
to each of PassRefPtr<Element>, PassRefPtr<EventTarget>,
PassRefPtr<EventTargetNode>, and PassRefPtr<Node> so it's not clear which
should be selected.

> The offending code looks as follows
> 
> 197:  PassRefPtr<WebCore::Element> ptr = gself->ownerElement();
> 198:  g_value_set_object (value, WebKit::toGDOM(ptr.get()));
> 
> Line 198 fails with the messages above. When the toGDOM functions are declared
> with raw pointer parameters, it compiles and runs properly.

Calling .get() on ptr just gives you back the same underlying pointer that
gself->ownerElement() returned, which would then be implicitly converted to a
new PassPrefPtr instance.  This would lead to the object being ref'd twice
rather than once (the ref would still be balanced as the local PassRefPtr would
deref when it goes out of scope).

To resolve the ambiguity you could pass ptr to toGDOM rather than ptr.get();,
since then no implicit type conversion will be required.  However, it's
probably a better idea to leave toGDOM taking a raw pointer instead.

> > There will be no need to give each variant of the function a
> > distinct name.  A simpler workaround if you can't convince the PassRefPtr
> > approach to work would be to use a raw pointer.  PassRefPtr is a matter of
> > optimization, not correctness.
> 
> Leaving the raw-pointer parameters is probably the solution, but I'm not sure
> if calling the toGDOM functions as shown above is the right way to do it. In
> particular, the local PassRefPtr variable looks suspicious to me, but it's hard
> for me to tell if this is OK in this particular case. I'd really appreciate
> some help here.

As I mentioned above there is a problem with the usage of PassRefPtr in the
code snippet you pasted.  Besides that, in existing code a local PassRefPtr is
only used when storing the return value of a function returning a PassRefPtr
before handing it off to a function accepting a PassRefPtr.  Using it in this
different manner doesn't feel quite right to me.

> By the way, should I ask these type of questions somewhere else? (IRC?, mailing
> list?)

Both #webkit and the webkit-dev mailing list would be a reasonable place to ask
this sort of question.


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