Support nullable types in mojom.

mojo/public/tools/bindings/pylib/mojom/generate/module.py

Index: mojo/public/tools/bindings/pylib/mojom/generate/module.py
diff --git a/mojo/public/tools/bindings/pylib/mojom/generate/module.py b/mojo/public/tools/bindings/pylib/mojom/generate/module.py
index c55b85e2e3313667dfaafb2bde993cbc12570ea2..c69a72610a39a2aa7f9d8d1959116d0542999d7a 100644
--- a/mojo/public/tools/bindings/pylib/mojom/generate/module.py
+++ b/mojo/public/tools/bindings/pylib/mojom/generate/module.py
@@ -126,6 +126,7 @@ class Array(Kind):
     else:
       Kind.__init__(self)
 
+
 class FixedArray(Kind):
   def __init__(self, length, kind=None):
     self.kind = kind
@@ -135,6 +136,7 @@ class FixedArray(Kind):
     else:
       Kind.__init__(self)
 
+
 class InterfaceRequest(Kind):
   def __init__(self, kind=None):
     self.kind = kind
@@ -211,6 +213,31 @@ class Enum(Kind):
     self.fields = []
 
 
+def SupportsNullable(kind):
+  if isinstance(kind, (Struct, Array, FixedArray, Interface, InterfaceRequest)):
+    return True
+
+  return (kind == STRING or kind == HANDLE or kind == DCPIPE or

[darin (slow to review), 2014/08/03 05:57:58]

what does it mean for a handle-type to be nullable? perhaps this falls out of
wanting to have nullable or non-nullable interfaces?

i'm also a bit curious what "interface&?" precisely means. i guess it means that
it is optional for the caller to not request a remote object (i.e., to not
supply a message pipe handle to be hooked up to a remote object). then, i
suppose "interface?&" might also be valid? that might mean it is OK for the
request to result in a null remote object? hmm... i wonder if that latter case
is useful.

[yzshen1, 2014/08/03 08:27:46]

I think for a handle type, nullable means it could be an invalid handle.

At the mojo message level, an interface is a handle. I think it is not very
different from other kinds of handles. The fact that interface is wrapped as
"pointer" is a bindings-level feature and may be subject to change. For example,
in the future, we may create a wrapper DataConsumerPtr for
handle<data_consumer_pipe>, and data_consumer_ptr.is_null() <=> the underlying
pipe handle is invalid.
Exactly, that is what I have in mind.
It is similar to passing a NULL pointer to an output parameter.
I think it may make sense to not support interface?&. Currently, we don't have a
way to distinguish "resulting in a NULL remote object" from "resulting in a
valid remote object but the connection is closed quickly after that".  We could
add support for sending back different error codes when the connection is
closed. But it doesn't seem very useful to me.

Another reason is that I wish "nullable" could have a very simple and consistent
meaning at the mojo message level: the pointer field may be NULL or the handle
field may be invalid. "interface?&" is different, the corresponding handle field
should always be valid! (If it is invalid, that is interface&?)

What do you think?

+          kind == DPPIPE or kind == MSGPIPE or kind == SHAREDBUFFER)
+
+
+class Nullable(Kind):

[darin (slow to review), 2014/08/03 05:57:58]

I'm kind of surprised to see Nullable as a subclass of Kind. Isn't it more of an
attribute of a Kind (or of the Kinds that can be nullable)?

[yzshen1, 2014/08/03 08:27:46]

I agree that it should be redesigned. The biggest issue is that it is awkward to
use:
kind1 = Struct('some_struct')
kind2 = Nullable(kind1)
|kind1| and |kind2| should both be considered as struct kinds, but we cannot
call |kind2.name/fields/etc.|!

I think alternative (1) is: both |kind1| and |kind2| are Struct instances, the
only difference that the |is_nullable| member of |kind2| is set to True. The
drawback is that a lot of members are duplicated in |kind1| and |kind2|.

Alternative (2): 
kind1 = Struct('some_struct')
kind2 = NullableStruct(kind1)
# NullableStruct defines properties pointing to corresponding members in Struct,
so that |kind2.name/fields/etc.| work as expected.
This doesn't have the drawback of alternative (1), but seems ugly. :/

What do you think?

+  def __init__(self, kind=None):
+    Kind.__init__(self)
+    self.kind = None
+
+    if kind is not None:
+      self.SetKind(kind)
+      if kind.spec is not None:
+        self.spec = '?' + kind.spec
+
+  def SetKind(self, kind):
+    if not SupportsNullable(kind):
+      raise Exception(
+          'A type (spec "%s") cannot be made nullable' % kind.spec)
+    self.kind = kind
+
+
 class Module(object):
   def __init__(self, name=None, namespace=None):
     self.name = name