mojo/public/tools/bindings/generators/java_templates/constant_definition.tmpl - Issue 291903003: Generate java bindings for constants.

Side by Side Diff: mojo/public/tools/bindings/generators/java_templates/constant_definition.tmpl

Issue 291903003: Generate java bindings for constants. (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: Add private constructor to constants class. Created 6 years, 7 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch | Annotate | Revision Log

« no previous file with comments | « mojo/not-to-commit/java_mojo/mojo_public_test_interfaces/src/org/chromium/mojo/bindings/test/sample/SampleServiceConstants.java ('k') | mojo/public/tools/bindings/generators/java_templates/constants.java.tmpl » ('j') | mojo/public/tools/bindings/generators/java_templates/constants.java.tmpl » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 {% from "java_macros.tmpl" import build_default %}

	2

	3 {% macro constant_def(constant) %}

	4 public static final {{constant.kind\|java_type}} {{constant\|constant_name}} = {{b uild_default(module, constant.kind, constant.value)\|indent(4)}};
	rmcilroy 2014/05/25 22:55:10 Do we need build_default()? The cpp binding gener Do we need build_default()? The cpp binding generator gets away withexpression_to_text(), I'm pretty sure we could too assuming a mojom const can't be anything other than a number or string literal? If not, could you add an examples to the the sample mojom files which use the other const types. qsr 2014/05/26 08:41:20 Updated build_default() to be a lot simpler, but Show quoted text On 2014/05/25 22:55:10, rmcilroy wrote: > Do we need build_default()? The cpp binding generator gets away > withexpression_to_text(), I'm pretty sure we could too assuming a mojom const > can't be anything other than a number or string literal? If not, could you add > an examples to the the sample mojom files which use the other const types. Updated build_default() to be a lot simpler, but I let it there, because this will also be used for default field value, and I'd like to let this at a single place if we ever update the idl to allow default array and struct as it was a few days ago. rmcilroy 2014/05/26 11:13:48 I am fine with build_default existing (and being u Show quoted text On 2014/05/26 08:41:20, qsr wrote: > On 2014/05/25 22:55:10, rmcilroy wrote: > > Do we need build_default()? The cpp binding generator gets away > > withexpression_to_text(), I'm pretty sure we could too assuming a mojom const > > can't be anything other than a number or string literal? If not, could you add > > an examples to the the sample mojom files which use the other const types. > > Updated build_default() to be a lot simpler, but I let it there, because this > will also be used for default field value, and I'd like to let this at a single > place if we ever update the idl to allow default array and struct as it was a > few days ago. I am fine with build_default existing (and being used for fields), but would prefer you use expression_to_text() here currently otherwise we are supporting a different IDL from the CPP generator. It would be easy to swap the filter used here if the IDL added back support for const arrays/structs. qsr 2014/05/26 12:33:43 I don't understand. The macro is only using expres I don't understand. The macro is only using expression_to_text(). rmcilroy 2014/05/27 09:44:34 I was presuming you were going to update the build Show quoted text On 2014/05/26 12:33:43, qsr wrote: > I don't understand. The macro is only using expression_to_text(). I was presuming you were going to update the build_default macro in a later CL to support arrays and objects again when it was used to build default field values - is this not the case? If not, then this is fine, though maybe renaming the macro to build_constant() would be clearer?
	5 {% endmacro %}

OLD	NEW