[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