[webkit-dev] Rationale for PlatformRefPtr?

[Darin Adler]

On Sep 30, 2010, at 5:12 PM, Martin Robinson wrote:

> It does not use compile-time settings, but template specialization.

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

It may seem like we can’t do this for RefPtr, but we almost certainly can. It currently works with any class with a ref and deref function, but recently I added this new feature,“adopted”, and overloaded it for every type. With a little bit of work Ithink we can make RefPtr work for the types inside WebKit but also for GObject, and Cairo. That will mean that RefPtr and PassRefPtr will both work for all of those. We can then add additional support for other types as long as they have base classes that can be distinguished for function overloading. I believe we can make this work for JSStringRef too, which means we could eliminate JSRetainPtr.

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.

    -- Darin