20.06.2011, в 21:55, David Levin написал(а):
PassRefPtr is useful even if the function doesn't take any kind of ownership.
It's useful when callers want to get rid of ownership, and then they can do
that efficiently.
I don't understand this. How it is more efficient to pass ownership if
On Jun 19, 2011, at 12:48 PM, Darin Adler wrote:
The arguments about abandoning PassRefPtr for arguments entirely are
attacking a straw man. We know PassRefPtr offers an important optimization
and do not want to drop that!
I posited it not as a straw man but rather as an option I myself
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
On Mon, Jun 20, 2011 at 9:19 AM, Alexey Proskuryakov a...@webkit.org wrote:
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
On Jun 20, 2011, at 9:19 AM, Alexey Proskuryakov wrote:
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
On Mon, Jun 20, 2011 at 5:25 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 20, 2011, at 9:19 AM, Alexey Proskuryakov wrote:
20.06.2011, в 03:22, Maciej Stachowiak написал(а):
For a shared ownership model there are multiple possible definitions of
whether a function takes ownership to
20.06.2011, в 17:25, Maciej Stachowiak написал(а):
Yet it's the latter where PassRefPtr is beneficial. Why base the rule on
something that's disconnected from actual benefit?
Because it's simpler to read the source of your own function than to visit
all call sites, and it's more obvious
On Mon, Jun 20, 2011 at 6:11 PM, Alexey Proskuryakov a...@webkit.org wrote:
20.06.2011, в 17:25, Maciej Stachowiak написал(а):
Yet it's the latter where PassRefPtr is beneficial. Why base the rule on
something that's disconnected from actual benefit?
Because it's simpler to read the
20.06.2011, в 21:29, David Levin написал(а):
Here's a few benefits:
1. It makes the code more self-documenting. It clearly indicates that this
function intends to take a reference to the item.
2. It is consistent with the rules for PassOwnPtr. It is nice to have one set
of things in mind
On Mon, Jun 20, 2011 at 9:39 PM, Alexey Proskuryakov a...@webkit.org wrote:
20.06.2011, в 21:29, David Levin написал(а):
Here's a few benefits:
1. It makes the code more self-documenting. It clearly indicates that
this function intends to take a reference to the item.
2. It is
The arguments about abandoning PassRefPtr for arguments entirely are attacking
a straw man. We know PassRefPtr offers an important optimization and do not
want to drop that!
On Jun 18, 2011, at 10:58 PM, Maciej Stachowiak wrote:
(1) Use PassRefPtr for every parameter that takes ownership.
I
On Sun, Jun 19, 2011 at 12:48 PM, Darin Adler da...@apple.com wrote:
Con (of abandoning PassRefPtr for function arguments entirely):
Possible accidental freed memory access bugs.
I think the reverse of this Con is one of the stronger Pro arguments for
using PassRefPtr even more for
On Jun 19, 2011, at 2:03 PM, Ryosuke Niwa wrote:
One of the most common security bugs I have seen in editing is that we keep a
raw pointer to a node and call some helper method that modifies DOM
(therefore invoking scripts).
I'm sometimes tempted to replace all instances of Node* in the
On Sun, Jun 19, 2011 at 2:05 PM, Darin Adler da...@apple.com wrote:
On Jun 19, 2011, at 2:03 PM, Ryosuke Niwa wrote:
One of the most common security bugs I have seen in editing is that we
keep a raw pointer to a node and call some helper method that modifies DOM
(therefore invoking
I've fixed many a security bug cause by not refing local variables.
Generally, you need to ref your local variables if any function you call can
end up executing JavaScript (and many can). If you're not sure, please feel
encouraged to ask around.
Adam
On Jun 18, 2011 8:54 PM, Darin Adler
On Jun 18, 2011, at 5:52 PM, Darin Adler wrote:
1:
Recently, Alexey has encouraged me to use PassRefPtr less for function
arguments.
The PassRefPtr optimization pays off when the object in question is possibly
being handed off from one PassRefPtr to another. For an argument, that can
18.06.2011, в 22:15, Maciej Stachowiak написал(а):
- I think having a rule for using PassRefPtr for arguments that depends on
how callers use the function is likely to be hard to use in practice, since
it requires global knowledge of all callers to pick the right function
signature. The
17 matches
Mail list logo
