Another implementation option would be to put all the dictionaries in a single
file and have a static global set of ids which works across all dictionaries
and is initialized once at startup or so. That would also handle cross-file
dictionary inheritance better.
One problem that remains is the fake descriptor business. At the moment this
does not allow interface types inside dictionaries. We could probably work
around this by either refactoring code to make it possible to get the declType
independently of the actual conversion template (whether because it lives in a
separate function or because the conversion template generator knows to just
return an empty string when the fake descriptor provirder is passed) or by
figuring out a way to pass an actual descriptor provider to dictionary codegen.
The big block in getRetvalDeclarationForType is just direct cut/paste from CGCallGenerator plus the addition of the sequence case. The IDL parser changes were OKed by khuey; they're needed so that we don't have to worry about the ordering of sequence with conversions for strings and primitives.
The changes in CastableObjectUnwrapper and CallbackObjectUnwrapper are
basically reindentation. Similar for the actual conversion changes for all the
non-interface types, though for those the actual declaration of the thing being
converted to has moved out, since we may not be converting onto the stack.
ErrorResult is in a separate header file so it can be included from all over the
place without having to pull in mozilla/dom/Utils.h and all the xpconnect gunk
that needs.
ErrorResult is in a separate header file so it can be included from all over the
place without having to pull in mozilla/dom/Utils.h and all the xpconnect gunk
that needs.
In the new setup, all per-interface DOM binding files are exported into
mozilla/dom. General files not specific to an interface are also exported into
mozilla/dom.
In terms of namespaces, most things now live in mozilla::dom. Each interface
Foo that has generated code has a mozilla::dom::FooBinding namespace for said
generated code (and possibly a mozilla::bindings::FooBinding_workers if there's
separate codegen for workers).
IDL enums are a bit weird: since the name of the enum and the names of its
entries all end up in the same namespace, we still generate a C++ namespace
with the name of the IDL enum type with "Values" appended to it, with a
::valuelist inside for the actual C++ enum. We then typedef
EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to
refer to the values, but means that values from different enums don't collide
with each other.
The enums with the proto and constructor IDs in them now live under the
mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively.
Again, this lets us deal sanely with the whole "enum value names are flattened
into the namespace the enum is in" deal.
The main benefit of this setup (and the reason "Binding" got appended to the
per-interface namespaces) is that this way "using mozilla::dom" should Just
Work for consumers and still allow C++ code to sanely use the IDL interface
names for concrete classes, which is fairly desirable.
Pass two objects when creating a DOM interface object, the global used to cache
the DOM interface objects and a receiver object on which the named property is
that points to the DOM interface object.
