[webkit-dev] Rationale for PlatformRefPtr?

[Darin Adler]

On Sep 30, 2010, at 6:21 PM, Martin Robinson wrote:

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

The name PlatformRefPtr really provokes me because it implies that it’s an abstraction that allows you to use the same code with multiple platforms, and I don’t think this happens in practice.

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

I think that means we’ll need a separate GRefPtr and thus might need to come up with some kind of macro technique if our aim is to avoid  copy and paste; but we can almost certainly make the primary RefPtr/PassRefPtr work with Cairo and JSStringRef if nothing else.

    -- Darin