The bindings have been getting much better lately, but we are running into a wall, performance wise, due to the need to gather information about interfaces/dictionaries/enums other than the one currently being generated. I would like to propose a new model, that should allow us to parse each IDL file at most once (or in a simplified form, at most twice). The basic idea is to formalize our current split processing (preprocess-idls.pl and generate-bindings.pl) into two phases, parsing and code generation, with a data structure, the 'type database' being used to bridge the gap between them. - In the parsing phase, we parse each IDL file and build up a 'type database' (essentially a big map of all the IDL types and their characteristics, parent type, exposure and compatibility aliases, inheritable extended attributes, named/indexed getters/setters, serializers, etc.) by extracting relevent information. Then, we dump the parsed form to a file so it can be reconstructed quickly, without re-parsing, using Storable (this is the optional step, we can always just do a second parse for code generation). - In the code generation phase, we take as input, an IDL file (or it's parsed form mapped in from disk) and the 'type database'. As a rule, all code generation should be possible with only those two input. If additional information is needed, it should be extracted during the parsing phase, and added to the 'type database'. (This leaves out partial interfaces and implements statements. We will probably want to do something like have them participate in the parsing phase just like any other IDL file, and then during code generation, we do a merge before the real generation has begun). Thoughts?
Sounds good to me.
Sounds super nice!
I don’t understand the lifetime of the type database file. Is it something that is left behind from one compilation and used for the next? Is it a global shared file?
(In reply to Darin Adler from comment #3) > I don’t understand the lifetime of the type database file. Is it something > that is left behind from one compilation and used for the next? Is it a > global shared file? I have to admit I don't entirely remember what I was thinking, as I filed this about 15 months ago, but I am pretty sure the idea was that it would be left over from one compilation to the next.