Mojo cpp bindings: support Clone() for structs and arrays which don't contain handles.

mojo/public/tools/bindings/generators/cpp_templates/wrapper_class_declaration.tmpl

Index: mojo/public/tools/bindings/generators/cpp_templates/wrapper_class_declaration.tmpl
diff --git a/mojo/public/tools/bindings/generators/cpp_templates/wrapper_class_declaration.tmpl b/mojo/public/tools/bindings/generators/cpp_templates/wrapper_class_declaration.tmpl
index 3f426a5f04bbe9d2d786a8cbcc5f7a17fdd45f45..21f29680ab20c006e0888f05c07466d29a9b85b7 100644
--- a/mojo/public/tools/bindings/generators/cpp_templates/wrapper_class_declaration.tmpl
+++ b/mojo/public/tools/bindings/generators/cpp_templates/wrapper_class_declaration.tmpl
@@ -21,6 +21,9 @@ class {{struct.name}} {
 
   {{struct.name}}();
   ~{{struct.name}}();
+{%  if struct|is_cloneable_kind %}
+  {{struct.name}}Ptr Clone() const;

[darin (slow to review), 2014/10/02 20:14:13]

Doesn't this potentially conflict with a user defined "Clone" function? Suppose
someone puts a method named "Clone" in their mojom that takes no parameters.

[Aaron Boodman, 2014/10/10 20:27:47]

It seems like it would. Since I am going to add Equals, was this question ever
resolved?

It seems like an alternate design would be to put these features on a generated
traits class, or as static members of {{struct.name}} class, or something.

[yzshen1, 2014/10/10 20:30:21]

This question has been resolved.

Clone() is defined on struct wrapper types, instead of interface types.
There isn't way for users to define functions for mojom structs. So I think it
won't be a problem.

[Aaron Boodman, 2014/10/10 21:04:15]

per our IM chat, this isn't resolved -- it is possible for user-defined fields
to conflict with these methods.

Users can't use the field name 'Clone'. In fact, this problem already existed --
Users can't use the field names 'New' or 'From' either.

The way I see it we can either just declare that mojom fields are always
unix_hacker_style, and so names starting with a capital are an open namespace
for bindings systems to use. Or else we can move these bindings-related methods
to some other traits class.

Darin, do you have an opinion?

[darin (slow to review), 2014/10/12 17:57:30]

Right, good catch. I'd be OK dictating that field names must start with a
lowercase letter. That matches every convention I know of, from
unix_hacker_style to camelCase, so it shouldn't make anyone sad.

Moving things to a traits class would work fine for Clone, but not for New and
From.

+{%- endif %}
 
 {#--- Getters #}
 {%  for field in struct.fields %}