Support nullable types in mojom.

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

 # 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.
 
 # This module's classes provide an interface to mojo modules. Modules are
 # collections of interfaces and structs to be used by mojo ipc clients and
 # servers.
 #
 # A simple interface would be created this way:
 # module = mojom.generate.module.Module('Foo')
@@ skipping 108 matching lines @@
 
 
 class Array(Kind):
   def __init__(self, kind=None):
     self.kind = kind
     if kind is not None:
       Kind.__init__(self, 'a:' + kind.spec)
     else:
       Kind.__init__(self)
 
+
 class FixedArray(Kind):
   def __init__(self, length, kind=None):
     self.kind = kind
     self.length = length
     if kind is not None:
       Kind.__init__(self, 'a' + length + ':' + kind.spec)
     else:
       Kind.__init__(self)
 
+
 class InterfaceRequest(Kind):
   def __init__(self, kind=None):
     self.kind = kind
     if kind is not None:
       Kind.__init__(self, 'r:' + kind.spec)
     else:
       Kind.__init__(self)
 
 
 class Parameter(object):
@@ skipping 56 matching lines @@
     self.name = name
     self.imported_from = None
     if name is not None:
       spec = 'x:' + name
     else:
       spec = None
     Kind.__init__(self, spec)
     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
     self.path = name
     self.namespace = namespace
     self.structs = []
     self.interfaces = []
 
   def AddInterface(self, name):
     interface=Interface(name, module=self);
     self.interfaces.append(interface)
     return interface
 
   def AddStruct(self, name):
     struct=Struct(name, module=self)
     self.structs.append(struct)
     return struct