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

 
 class {{struct.name}} {
  public:
   typedef internal::{{struct.name}}_Data Data_;
 
 {#--- Constants #}
 {%- for constant in struct.constants %}
   static const {{constant.kind|cpp_pod_type}} {{constant.name}};
 {%- endfor %}
 {#--- Enums #}
 {%- for enum in struct.enums -%}
 {%    macro enum_def() %}{% include "enum_declaration.tmpl" %}{% endmacro %}
   {{enum_def()|indent(2)}}
 {%- endfor %}
   static {{struct.name}}Ptr New();
 
   template <typename U>
   static {{struct.name}}Ptr From(const U& u) {
     return mojo::TypeConverter<{{struct.name}}Ptr, U>::Convert(u);
   }
 
   {{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 %}
 {%-   set type = field.kind|cpp_wrapper_type %}
 {%-   set name = field.name %}
   {{type}} {{name}};
 {%- endfor %}
 };