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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
