Mojo: more idiomatic C++ bindings

mojo/public/tools/bindings/generators/cpp_templates/module.h.tmpl

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 {%- set header_guard = "%s_H_"|
         format(module.path|upper|replace("/","_")|replace(".","_")) %}
 
 #ifndef {{header_guard}}
 #define {{header_guard}}
 
 #include "mojo/public/cpp/bindings/array.h"
 #include "mojo/public/cpp/bindings/callback.h"
 #include "mojo/public/cpp/bindings/interface_impl.h"
 #include "mojo/public/cpp/bindings/interface_ptr.h"
 #include "mojo/public/cpp/bindings/message_filter.h"
 #include "mojo/public/cpp/bindings/no_interface.h"
+#include "mojo/public/cpp/bindings/string.h"
+#include "mojo/public/cpp/bindings/struct_ptr.h"
 #include "{{module.path}}-internal.h"
 {%- for import in imports %}
 #include "{{import.module.path}}.h"
 {%- endfor %}
 
 {%- for namespace in namespaces_as_array %}
 namespace {{namespace}} {
 {%- endfor %}
 
 {#--- Constants #}
 {%  for constant in module.constants %}
 extern const {{constant.kind|cpp_pod_type}} {{constant.name}};
 {%- endfor %}
 
 {#--- Enums #}
 {%  for enum in enums %}
 {%    include "enum_declaration.tmpl" %}
 {%- endfor %}
 
 {#--- Interface Forward Declarations -#}
 {%  for interface in interfaces %}
 class {{interface.name}};
 typedef mojo::InterfacePtr<{{interface.name}}> {{interface.name}}Ptr;
 {%  endfor %}
 
+{#--- Struct Forward Declarations -#}
+{%  for struct in structs %}
+class {{struct.name}};
+{%    if struct|should_inline %}
+typedef mojo::InlinedStructPtr<{{struct.name}}> {{struct.name}}Ptr;

[yzshen1, 2014/05/22 17:13:53]

It seems users always create/use FooPtr instead of Foo directly.
If that is true, does it make sense to change the names:
Foo -> Foo_Data
FooPtr -> Foo

Pros:
- It seems less verbose to the users.
- It is more consistent with the mojom definition: if user defines struct Foo{}
in the mojom file, he/she will use a cpp class called Foo.
- It is more consistent with Array and String, because they are not called
ArrayPtr and StringPtr.

What do you think?

+{%      include "wrapper_class_declaration.tmpl" %}
+{%    else %}
+typedef mojo::StructPtr<{{struct.name}}> {{struct.name}}Ptr;
+{%    endif %}
+{%  endfor %}
+
 {#--- Structs #}
 {%  for struct in structs %}
-{%    include "wrapper_class_declaration.tmpl" %}
+{%    if not struct|should_inline %}
+{%      include "wrapper_class_declaration.tmpl" %}
+{%    endif %}
 {%- endfor %}
 
 {#--- Interfaces -#}
 {%  for interface in interfaces %}
 {%    include "interface_declaration.tmpl" %}
 {%- endfor %}
 
 {#--- Interface Proxies -#}
 {%  for interface in interfaces %}
 {%    include "interface_proxy_declaration.tmpl" %}
 {%- endfor %}
 
 {#--- Interface Stubs -#}
 {%  for interface in interfaces %}
 {%    include "interface_stub_declaration.tmpl" %}
 {%- endfor %}
 
 {#--- Interface Request Validators -#}
 {%  for interface in interfaces %}
 {%    include "interface_request_validator_declaration.tmpl" %}
 {%- endfor %}
 
 {#--- Interface Response Validators -#}
 {%  for interface in interfaces if interface|has_callbacks %}
 {%    include "interface_response_validator_declaration.tmpl" %}
 {%- endfor %}
 
+{#--- Struct Serialization Helpers -#}
+{%  if structs %}
+{%    for struct in structs %}
+{%      include "struct_serialization_declaration.tmpl" %}
+{%-   endfor %}
+{%- endif %}
+
 {%- for namespace in namespaces_as_array|reverse %}
 }  // namespace {{namespace}}
 {%- endfor %}
 
 {#--- Enum TypeTraits Specializations #}
-{%  if enums %}
 namespace mojo {
 namespace internal {
+{%  if enums %}
 {%    for enum in enums %}
 {%      include "enum_traits.tmpl" %}
 {%-   endfor %}
+{%- endif %}
 }  // namespace internal
 }  // namespace mojo
-{%- endif %}
 
 #endif  // {{header_guard}}