[Webkit-unassigned] [Bug 153617] Add a variadic function template for creating new RefCounted objects and use it instead of the numerous per-class create() functions
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Feb 8 13:13:38 PST 2016
https://bugs.webkit.org/show_bug.cgi?id=153617
Andy Estes <aestes at apple.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|webkit-unassigned at lists.web |aestes at apple.com
|kit.org |
--- Comment #2 from Andy Estes <aestes at apple.com> ---
Created attachment 270876
--> https://bugs.webkit.org/attachment.cgi?id=270876&action=review
Proof of concept
I took a stab at this over the weekend. Here's a proof of concept with a few examples of how this would be adopted.
I ended up adding a static create function in WTF::Ref. It's not possible to do this correctly in RefCounted, since the RefCounted template is not always instantiated with the class that needs to be constructed. I like the way this ended up looking, since it plays really nicely with auto, e.g.:
auto stopwatch = Ref<Stopwatch>::create();
There are a few things I don't love about this approach, though:
1. Classes that wish to use this function need to become friends with WTF::Ref so that it can call their private/protected constructors. Making constructors public would defeat the point of this exercise, so this is probably an acceptable trade-off.
2. Some classes have non-trivial create functions, where extra work needs to be done before or after calling constructors, and some classes even return a null RefPtr in some cases. Those classes should be ineligible for using Ref::create() (even though they might choose to use that function internally). I'd like to add some enforcement at compile time that prevents callers from using Ref::create if a per-class create function exists. It might make sense to add a trait to classes that wish to retain a custom create function that Ref::create can static_assert() on.
I'd welcome any feedback on how to make this better!
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160208/a88d3006/attachment-0001.html>
More information about the webkit-unassigned
mailing list