Jon Smirl wrote: > Do you want to make classInfo a required interface? I really think > getInterfaces() needs to be a required interface. classInfo burns 14 vtable > entries per object class and will probably add something around 100K to the > memory footprint. I was hoping you could work out a scheme for doing > queryInterface and getInterface off from the same table and add very little > to the footprint. One macro might be able to generate both methods.
The current _CI macros, IIRC, share data between the getInterfaces call and QI. Are you finding otherwise? (There was much gnashing of teeth and furling of brow over table-driven QI at one point, in the hopes that it would make our implementation sizes smaller. Alas, it wasn't to be with then-modern compilers on Linux.) > One scheme for marking things like thread safety and content-scriptability > would be to add a zero method interface to the object. You could then > queryInterface or getInterfaces for it. If it is there the attribute is > supported. Yes, and we've done this in other places. I really don't understand why CI doesn't solve your problem, though. And I don't see how your mechanism will give us things like class name and contract ID and CID lists, which we also get from the CI data, to great effect. And before you start leading a crusade about the vtable footprint, I think you should do some measurements. I believe that we currently share one implementation of nsIClassInfo across all generic-module-using components, which reaches into per-module data to answer queries. Mike
