Alias deref -> unref. This allows Skia objects to be held by WTF::RefPtr

Alias deref -> unref. This allows Skia objects to be held by WTF::RefPtr
smart pointers without need for another smart pointer type.

Note that the semantics of SkRefCnt match those WTF expects. In
particular, newly created objects have refcount 1 and objects are
deallocated at refcount 0.

This seems like a better fit than the AddRef/Release alises which exist
for scoped_ptr (but seem unused).

BUG=254509
Committed: http://code.google.com/p/skia/source/detail?r=9784

[reed1, 2013-06-26 19:29:45]

lgtm

[bungeman-skia, 2013-06-26 20:00:50]

On 2013/06/26 19:29:45, reed1 wrote:
> lgtm

I see no reason for this, there is already skia:RefPtr available (in skia/ext).
We should certainty be removing AddRef/Release.

[jbroman, 2013-06-26 20:02:14]

On 2013/06/26 20:00:50, bungeman1 wrote:
> On 2013/06/26 19:29:45, reed1 wrote:
> > lgtm
> 
> I see no reason for this, there is already skia:RefPtr available (in
skia/ext).
> We should certainty be removing AddRef/Release.

Blink policy forbids using skia::RefPtr (which lives in Chromium) right now. See
https://codereview.chromium.org/17448009#msg6

[reed1, 2013-06-26 20:13:15]

On 2013/06/26 20:02:14, jbroman wrote:
> On 2013/06/26 20:00:50, bungeman1 wrote:
> > On 2013/06/26 19:29:45, reed1 wrote:
> > > lgtm
> > 
> > I see no reason for this, there is already skia:RefPtr available (in
> skia/ext).
> > We should certainty be removing AddRef/Release.
> 
> Blink policy forbids using skia::RefPtr (which lives in Chromium) right now.
See
> https://codereview.chromium.org/17448009#msg6

No value in reopening this debate (imho). Landing this costs Skia almost nothing
(aliases in the public api are cheap (enough)). lgtm

[bungeman-skia, 2013-06-26 20:16:55]

> Note that the semantics of SkRefCnt match those WTF expects. In 
> particular, newly created objects have refcount 1 and objects are 
> deallocated at refcount 0.

Note that this is not true. WTF expects objects to start with a reference count
of 0, and are expected to go to a reference count of 1 when first assigned
(WTF::RefPtr(T*) refs is argument, expecting newly created objects to have a
reference count of 0). The use (with this change) would have to be something
like

WTF::RefPtr<SkRefCnt> refPtr(refCnt);
refCnt->unref();

Which is really, really error prone. There doesn't appear to be a publicly
accessible meas to avoid this (such as an AdoptRef), but I could be missing it.

[jbroman, 2013-06-26 20:51:36]

On 2013/06/26 20:16:55, bungeman1 wrote:
> > Note that the semantics of SkRefCnt match those WTF expects. In 
> > particular, newly created objects have refcount 1 and objects are 
> > deallocated at refcount 0.
> 
> Note that this is not true. WTF expects objects to start with a reference
count
> of 0, and are expected to go to a reference count of 1 when first assigned
> (WTF::RefPtr(T*) refs is argument, expecting newly created objects to have a
> reference count of 0). The use (with this change) would have to be something
> like
> 
> WTF::RefPtr<SkRefCnt> refPtr(refCnt);
> refCnt->unref();

No, you wouldn't. I think you're thinking of Chromium's scoped_refptr (more on
that later).

> Which is really, really error prone. There doesn't appear to be a publicly
> accessible meas to avoid this (such as an AdoptRef), but I could be missing
it.

Yes, there is. It's even called adoptRef.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

And if you look at wtf/RefCounted.h, you'll note that its ref count is
explicitly initialized to 1.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

The document which explains RefPtr also explicitly says "Objects are created
with a reference count of 1." (http://www.webkit.org/coding/RefPtr.html).

Finally, I have tests which validate that WTF::RefCounted and SkRefCnt behave
identically in this regard (see crbug.com/254509).

[bungeman-skia, 2013-06-26 21:07:01]

Ah, I see you have to do

WTF::RefPtr<SkRefCnt> blah(WTF::adoptref(refCnt));

or an assignment. The thing that was throwing me off is that adoptRef creates a
PassRefPtr. RefPtr then doesn't increment on being constructed from one.

I still don't like cluttering the Skia namespace with this, but Mike says ok.

[commit-bot: I haz the power, 2013-06-26 21:12:00]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/jbroman@chromium.org/17880003/1

[bungeman-skia, 2013-06-26 21:26:35]

Oh, and yes, I was thinking of Chromium's RefCountedBase instead of WTF's
RefCounted.

[commit-bot: I haz the power, 2013-06-26 22:20:24]

Change committed as 9784