Re: [webkit-dev] Rationale for PlatformRefPtr?
On Thu, Sep 30, 2010 at 4:53 PM, Martin Robinson <martin.james.robinson@gmail.com> wrote:
On Thu, Sep 30, 2010 at 3:20 PM, Darin Adler <darin@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
On Sep 30, 2010, at 4:54 PM, Martin Robinson wrote:
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).
But couldn’t someone get into a situation where they want to use GObject and Cairo reference counted types in the same port?
We'd like to share the same templated class for all of these smart pointers to avoid duplicate code.
If this is the goal, there are multiple ways to achieve it. There are template techniques to do it that we decided not to use before, because the tools don’t support them well enough. There are macro techniques to do it that we could use right now and then we could have these new classes share code with RefPtr, RetainPtr, and JSRetainPtr as well. Making one class that is one of these three based on a compile-time setting does not seem like the right way to go to me. -- Darin
On Thu, Sep 30, 2010 at 5:02 PM, Darin Adler <darin@apple.com> wrote:
But couldn’t someone get into a situation where they want to use GObject and Cairo reference counted types in the same port?
This is the situation with the GTK+ port now. The GTK+ port simply adds template specializations for GObject types in the GRefPtr.h header and the Cairo code includes template specializations for Cairo types.
We'd like to share the same templated class for all of these smart pointers to avoid duplicate code. If this is the goal, there are multiple ways to achieve it. There are template techniques to do it that we decided not to use before, because the tools don’t support them well enough. There are macro techniques to do it that we could use right now and then we could have these new classes share code with RefPtr, RetainPtr, and JSRetainPtr as well.
I think this would be great. I'd be happy to embark on this.
Making one class that is one of these three based on a compile-time setting does not seem like the right way to go to me.
It does not use compile-time settings, but template specialization. Sorry if I misrepresented that. Martin
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
On Thu, Sep 30, 2010 at 5:46 PM, Darin Adler <darin@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. Martin
On Sep 30, 2010, at 6:21 PM, Martin Robinson wrote:
On Thu, Sep 30, 2010 at 5:46 PM, Darin Adler <darin@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
participants (2)
-
Darin Adler
-
Martin Robinson