Move chrome.downloads out of experimental to dev

tools/json_schema_compiler/h_generator.py

 # Copyright (c) 2012 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.
 
 from code import Code
 from model import PropertyType
 import cpp_util
-import model
-import os
 import schema_util
 
 class HGenerator(object):
   """A .h generator for a namespace.
   """
   def __init__(self, namespace, cpp_type_generator):
     self._cpp_type_generator = cpp_type_generator
     self._namespace = namespace
     self._target_namespace = (
         self._cpp_type_generator.GetCppNamespaceName(self._namespace))
@@ skipping 84 matching lines @@
     """Generates the list of types in the current namespace in an order in which
     depended-upon types appear before types which depend on them.
     """
     dependency_order = []
 
     def ExpandType(path, type_):
       if type_ in path:
         raise ValueError("Illegal circular dependency via cycle " +
                          ", ".join(map(lambda x: x.name, path + [type_])))
       for prop in type_.properties.values():
-        if not prop.optional and prop.type_ == PropertyType.REF:
+        if schema_util.IsLocalReference(prop, self._namespace.name):

[not at google - send to devlin, 2012/06/07 03:00:54]

IsReferenceInNamespace?

though I would still have preferred

if prop.type_ == PropertyType.REF and \
   schema_util.GetNamespace(prop.ref_type) != self._namespace.name:

because passing a function that only operates on a certain type (here, REF)
shouldn't need to check that what it's passed is that type. it should raise an
error if it's not the type that it's passed.

besides which, we shouldn't be adding such specific functionality to util
classes.  over-specific util classes (util classes in general, actually) tend to
just make the code that uses them harder to understand, at least, for me.

[benjhayden, 2012/06/08 16:41:52]

Done.

           ExpandType(path + [type_], self._namespace.types[prop.ref_type])
       if not type_ in dependency_order:
         dependency_order.append(type_)
 
     for type_ in self._namespace.types.values():
       ExpandType([], type_)
     return dependency_order
 
   def _GenerateEnumDeclaration(self, enum_name, prop, values):
     """Generate the declaration of a C++ enum for the given property and
@@ skipping 46 matching lines @@
       if type_.description:
         c.Comment(type_.description)
       c.Append('typedef std::vector<%(item_type)s> %(classname)s;')
       c.Substitute({'classname': classname, 'item_type':
           self._cpp_type_generator.GetType(type_.item_type,
                                            wrap_optional=True)})
     elif type_.type_ == PropertyType.STRING:
       if type_.description:
         c.Comment(type_.description)
       c.Append('typedef std::string %(classname)s;')
-      c.Substitute({'classname': classname})
+    elif type_.type_ == PropertyType.DOUBLE:
+      if type_.description:
+        c.Comment(type_.description)
+      c.Append('typedef double %(classname)s;')
+    elif type_.type_ == PropertyType.INTEGER:
+      if type_.description:
+        c.Comment(type_.description)
+      # TODO(benjhayden): c.Sblock('enum %(classname)s {') ... .Eblock('};')
+      # Generated cpp code should contain all constants defined in the IDL so
+      # that they don't need to be copied between the IDL and the
+      # implementation. This requires correctly parsing and transmitting the
+      # constants' names from the IDL to here. The same goes for string and
+      # double enums.

[not at google - send to devlin, 2012/06/07 03:00:54]

We do generate code for constants that are defined inside properties.

Anyway, if I understand this correctly, this comment only applies for when the
type is an integer... and an enum? So a more accurate TODO would be

TODO: if this type is an enum, generate an enum block with the corresponding
values.

that said, I don't know if that'd even be possible, since those enums don't have
names... they're just part of the constraints of the types themselves, and we
don't do that kind of validation as part of this compiler.

So yeah, in summary: I don't think this should be a TODO :)

[benjhayden, 2012/06/08 16:41:52]

Antony suggested using extended attributes to be more compliant with the WebIDL
spec:
http://codereview.chromium.org/9617010/diff/71002/chrome/common/extensions/ap...

+      c.Append('typedef int %(classname)s;')
     else:
       if type_.description:
         c.Comment(type_.description)
       (c.Sblock('struct %(classname)s {')
           .Append('~%(classname)s();')
           .Append('%(classname)s();')
           .Append()
           .Concat(self._GeneratePropertyStructures(type_.properties.values()))
           .Concat(self._GenerateFields(type_.properties.values()))
       )
@@ skipping 104 matching lines @@
           c.Comment(param.description)
         if param.type_ == PropertyType.ANY:
           c.Comment("Value* Result::Create(Value*) not generated "
                     "because it's redundant.")
           continue
         c.Append('Value* Create(const %s);' % cpp_util.GetParameterDeclaration(
             param, self._cpp_type_generator.GetType(param)))
     c.Eblock('};')
 
     return c