Extend the geometry APIs.

mojo/services/geometry/cpp/geometry_util.h

Index: mojo/services/geometry/cpp/geometry_util.h
diff --git a/mojo/services/geometry/cpp/geometry_util.h b/mojo/services/geometry/cpp/geometry_util.h
index 3d4d35eec467bfeb4bcabaae7e0d94b266c0ee72..97271c9057d97dd2218b65926b3b6f5eff188054 100644
--- a/mojo/services/geometry/cpp/geometry_util.h
+++ b/mojo/services/geometry/cpp/geometry_util.h
@@ -5,7 +5,7 @@
 #ifndef MOJO_SERVICES_GEOMETRY_CPP_GEOMETRY_UTIL_H_
 #define MOJO_SERVICES_GEOMETRY_CPP_GEOMETRY_UTIL_H_
 
-#include "geometry/interfaces/geometry.mojom.h"
+#include "mojo/services/geometry/interfaces/geometry.mojom.h"

[viettrungluu, 2015/12/17 23:05:29]

Hmmm. So, not having "mojo/services/" before was "correct" according to some
philosophy (which we haven't adhered to very strictly).

I wonder if we should stick to that philosophy, or eliminate it. (See my comment
in the BUILD.gn file.)

[jeffbrown, 2015/12/18 01:41:22]

This change was probably unintentional (since this code used to live elsewhere
before it was moved here) but shows the downsides of those relative includes.

I think in general it's easier to work with the source tree if we either say
that all includes should be global or all should be relative (and have the build
system introduce the necessary include paths as part of declaring dependencies
on other modules).

[viettrungluu, 2015/12/18 02:05:36]

I think it's definitely easier for us. The original rationale was (something
like) that consumers may want to put the code somewhere else.

Probably, for now (especially since we're not consistent about this and no one
puts the code anywhere else) it's easier to go with absolute paths.

When we get around to a packaging system for C++ libraries, etc., we can worry
about this....

 
 namespace mojo {
 
@@ -34,6 +34,9 @@ inline bool operator!=(const Point& lhs, const Point& rhs) {
   return !(lhs == rhs);
 }
 
+void SetIdentityTransform(Transform* transform);

[viettrungluu, 2015/12/17 23:05:29]

I wonder if it wouldn't be more natural for these to return a |Transform|
instead. (I don't feel strongly about this at all.)

[jeffbrown, 2015/12/18 01:41:22]

I considered that but this ended up being more general.  Works well for
stack-allocated objects too.  I also considered making "SetTranslationTransform"
into something more like a post-concatenation operation but decided to leave
that for another day.

[viettrungluu, 2015/12/18 02:05:36]

OK.

+void SetTranslationTransform(Transform* transform, float x, float y, float z);
+
 }  // namespace mojo
 
 #endif  // MOJO_SERVICES_GEOMETRY_CPP_GEOMETRY_UTIL_H_