[webkit-dev] Rationale for PlatformRefPtr?
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