[webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more

[Alexey Proskuryakov]

20.06.2011, в 03:22, Maciej Stachowiak написал(а):

>> For a shared ownership model there are multiple possible definitions of whether a function takes ownership to an object passed as an argument. Here are some of my attempts to describe the bright line:
>> 
>>    a) Hands off ownership to what could possibly be the sole owner in most code paths.
>>    b) Keeps a reference to the object after the function completes in most code paths.
>>    c) Takes a reference to the object at least once in most code paths.
>> 
>>    d) Hands off ownership to what could possibly be the sole owner in some code paths.
>>    e) Keeps a reference to the object after it completes in some code paths.
>>    f) Takes a reference to the object at least once in some code paths.
>> 
>> Is the bright line rule you have in mind (b) or perhaps (e)? Or something not listed here at all?
> 
> Yes, (b) or (e). I haven't thought about whether "most code paths" or "some code paths" makes more sense, but I'm not sure there are a lot of cases in our code where it makes a difference.
> 
> I don't think it makes sense to talk about a sole owner of a refcounted object. If there is a sole owner at any given time, it is at best temporary. PassRefPtr is about clearly and efficiently transferring a reference, it doesn't need it to necessarily be the sole then-existing reference.

I think that to make this complete, the rules need to be transitive. A function that passes its argument to another function taking a PassRefPtr should itself take a PassRefPtr. That's the case in <https://bugs.webkit.org/show_bug.cgi?id=52981>, for instance.

It doesn't seem that analyzing code for "most/some code paths takes ownership" would be any easier that analyzing it for "any caller gives away ownership". Yet it's the latter where PassRefPtr is beneficial. Why base the rule on something that's disconnected from actual benefit?

- WBR, Alexey Proskuryakov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110620/c18d8972/attachment.html>