[webkit-dev] Rationale for PlatformRefPtr?

Martin Robinson mrobinson at webkit.org
Thu Sep 30 18:21:31 PDT 2010

On Thu, Sep 30, 2010 at 5:46 PM, Darin Adler <darin at apple.com> wrote:
> If we can collapse multiple smart pointer types based on overloading, I think that’s great. In those cases, I think it’s OK to have a single RefPtr class that can handle multiple types as long as we can come up with a good name. But I don’t see a “Platform” concept here. It’s just a RefPtr that can handle a set of types that can all be distinguished at compile time.

I'm fine with any rename. I was not particularly fond of
PlatformRefPtr, I just couldn't think of anything more appropriate.

> I don’t think template specialization is needed. All we need is a single pair of functions that implement the ref/deref operations. Those functions can be overloaded for any number of types as long as the overloading is unambiguous.

This sounds great to me.

> Because the base class for Core Foundation is just a “const void*”, we can’t use this to eliminate RetainPtr, but I think we can eliminate almost all the other classes this way.

I believe this is also a problem for GObject unfortunately.


More information about the webkit-dev mailing list