views: Make View::set_border() take a scoped_ptr<>.

ui/views/view.h

Index: ui/views/view.h
diff --git a/ui/views/view.h b/ui/views/view.h
index aba1194ea2f5b1ed3a77d42604437a39e2e6df84..54bc2eff063d665ff21071a622fea0d29feeda31 100644
--- a/ui/views/view.h
+++ b/ui/views/view.h
@@ -513,7 +513,8 @@ class VIEWS_EXPORT View : public ui::LayerDelegate,
   Background* background() { return background_.get(); }
 
   // The border object is owned by this object and may be NULL.
-  void set_border(Border* b);
+  void SetBorder(scoped_ptr<Border> b);
+  void ClearBorder();

[sky, 2014/01/23 15:30:54]

Why do we need ClearBorder? I get that it saves some code, but from an API
standpoint I don't like it. I prefer callers use SetBorder with an empty
scopedptr.

[Elliot Glaysher, 2014/01/23 18:55:26]

Because it's really visually ugly and not clear at a glance.

It was a common pattern in our code to do "set_border(NULL);" to clear a border.
That's not great semantically, but is still tolerable.

"SetBorder(scoped_ptr<views::Border>());" isn't immediately clear like NULL is,
and it's generally better to have function names document what they're doing (in
this case, we're almost always clearing a border set by our base class).

[sky, 2014/01/23 19:39:36]

That argument applies anywhere we take a scoped_ptr now. To my knowledge we are
not adding explicit 'clear' methods every where.
I'm still against ClearBorder. I don't like bloating the API.

   const Border* border() const { return border_.get(); }
   Border* border() { return border_.get(); }