[webkit-dev] Rationale for PlatformRefPtr?

[Martin Robinson]

On Thu, Sep 30, 2010 at 4:53 PM, Martin Robinson
<martin.james.robinson at gmail.com> wrote:
> On Thu, Sep 30, 2010 at 3:20 PM, Darin Adler <darin at apple.com> wrote:
>> For example, for Core Foundation and Cocoa we made RetainPtr. For JavaScript we made JSRetainPtr. For GTK I think we should have GTKRefPtr.
>> Is there really code where the abstraction of having a single shared PlatformRefPtr is useful? Could someone show me an example of this working?

Resent from correct address:

Hey Darin,

I'll try to clear up the confusion around this and perhaps clearer
minds can suggest a better approach. There are several ports that use
third party libraries with reference counted types. GTK+ / EFL / and
gstreamer based ports use GObject and its associated
reference-counting mechanism. In addition, Cairo-based ports
(including GTK+ and the WinCairo port) use Cairo reference counted
types (which don't use GObject) and ports that use FontConfig also
have reference counted types (that is also unrelated to GObject or
Cairo).

We'd like to share the same templated class for all of these smart
pointers to avoid duplicate code. So the idea is that PlatformRefPtr
is a smart pointer for your platform-specific reference counted
pointers. Unless there is some smart way to do this, to have a
GRefPtr, CairoRefPtr and FontConfigRefPtr we would have to duplicate
the entire class (which is the way that JSRetainPtr and RetainPtr
work).

I'm not attached to the name in any way. I would just like for these
different ports to share a smart pointer class.

Martin