[PPAPI] Moving pp::VarResource_Dev API into pp::Var (now stable).

ppapi/cpp/var.h

Index: ppapi/cpp/var.h
diff --git a/ppapi/cpp/var.h b/ppapi/cpp/var.h
index 5cb26d9ee83a00d0ff41b0fccf259adf0f38cd0c..6328d49a4fe3afe241d301ee265962b27c228bee 100644
--- a/ppapi/cpp/var.h
+++ b/ppapi/cpp/var.h
@@ -10,6 +10,7 @@
 
 #include "ppapi/c/pp_var.h"
 #include "ppapi/cpp/pass_ref.h"
+#include "ppapi/cpp/resource.h"
 
 /// @file
 /// This file defines the API for handling the passing of data types between
@@ -50,6 +51,9 @@ class Var {
   /// A constructor used to create a UTF-8 character <code>Var</code>.
   Var(const std::string& utf8_str);  // Must be encoded in UTF-8.
 
+  /// A constructor used to create a resource <code>Var</code>.
+  explicit Var(const pp::Resource& resource);

[yzshen1, 2014/02/06 18:02:58]

Now that all the others are not 'explicit', maybe we should also support
implicit conversion in this case?

[dmichael (off chromium), 2014/02/06 18:33:14]

I think I prefer that the developer has to know that they're converting a
pp::Resource to a pp::Var, and aren't doing it by accident. (Admittedly, you
could say the same thing about the other ones, but I don't really like those
either :-p ).

[yzshen1, 2014/02/06 19:58:18]

I slightly prefer to be consistent. But I am fine with either approach. :)

[Matt Giuca, 2014/02/07 03:11:22]

I briefly discussed this with sammc@ yesterday. He argued that if it's a managed
(ref-counted) type then it should be explicit, but primitives don't have to be.
That was the rationale for making this one explicit.

I don't have a strong preference, though. Can you guys make a decision?

(Note: we can remove "explicit" later without breaking apps, but we cannot add
"explicit".)

[dmichael (off chromium), 2014/02/07 17:45:28]

I agree in thinking this one is a little different from primitives.
Additionally, we have a lot of functions that take pp::Var, and if we add this
constructor as implicit, it will suddenly be possible to accidentally pass a
pp::Resource in, and the compiler won't catch you. We'd be turning something
that currently is a compile-time mistake in to a runtime mistake. There's really
only 1 function where passing a pp::Resource as a pp::Var currently makes sense,
and that's PostMessage. I think the risk of making mistakes in other APIs
outweighs the benefits of being able to say "PostMessage(my_resource)" instead
of "pp::Var(my_resource)".

Yuzhu, are you okay with that direction?

[yzshen1, 2014/02/07 17:49:36]

Yeah. Your argument makes good sense. I agree we should do it with 'explicit'.
Thanks!

+
   /// A constructor used when you have received a <code>Var</code> as a return
   /// value that has had its reference count incremented for you.
   ///
@@ -211,6 +215,11 @@ class Var {
   /// @return A string version of this <code>Var</code>.
   std::string AsString() const;
 
+  /// Gets the resource contained in the var.
+  ///
+  /// @return The <code>pp::Resource</code> that is contained in the var.
+  pp::Resource AsResource() const;
+
   /// This function returns the internal <code>PP_Var</code>
   /// managed by this <code>Var</code> object.
   ///