The generic factory/module macros allow registration of both constructors and class object-related callbacks. It's not possible, however, to register to get a class object (and, hence, provide class info) without also creating a factory. There are situations where a module writer may want to have class info for an implementation class without making it instantiable via XPCOM. The macros should be able to take a null constructor, yet still accept the class object callbacks.

r/sr=jband vidur and I talked about just-in-time schemes for factory/classinfo object creation. We didn't like anything we came up with. It would be nice to defer this until someone tries to QI for nsIClassInfo. But the additional coupling required to do that was nasty. Still, this eager creation scheme may come back to haunt us. But we imagine the numbers will be small. vidur: Don't you want to reassign this to yourself?

The idea that we considered for a while was to lazily create the class object either in the classinfo-friendly QI macro or in a macro included in the constructor of such a class. To create the class object, we'd have to call NSGetModule (or the module-specific named entry point in the static build) to get the module instance and call nsIModule::GetClassObject on it. Reassigning the bug to myself.

r/sr=jst

Hey, I wanted this patch recently, for the FastLoad stuff (jband heard this). I have a patch in bug 68045 that makes caps/src/nsScriptSecurityManager.cpp call CreateInstance instead of new nsFooPrincipal, precisely so that serialization code can get class IDs via nsIClassInfo. I'd love to undo my change there if an updated version of vidur's patch can be landed first (sorry I caused conflicts in nsISupportsUtils.h!). /be

D'oh, I need non-null constructor functions for the caps generic factories, and I need classinfo hook-up even if caps chooses to optimize away CreateInstance calls via operator new. So what I want is a eager generic factory creation, eager meaning *before first CreateInstance, at module registration time*. That's a separate bug, but I'm soliciting comments here before filing it. Jband, shaver, dbaron, any thoughts on whether we're going to bloat excessively if we eagerly create generic factories? If so, perhaps we need another flag in nsModuleComponentInfo. /be

You mean "module initialization time". I vote for the added flag. You'd have to measure the impact, but my hunch is that on a normal run we don't instantiate half of those registered factories. I think eager in general would be bad. Vidur was specifically interested in not have his classes show up in the registry.

XPCOM is a disease, but I am not the cure. :-) What I mean is, I don't know why the principals classes need to be in the registry either, except to make them serializable. I could have invented a non-XPCOM scheme to do that, but everyone loves nsISupports and nsCOMPtr. When in Rome.... Ok, I'll file a separate bug and get out of this one. Although (if you take out the unnecessary nsISupportsUtils.h part of this bug's patch) I can offer vidur an sr=brendan@mozilla.org. /be

The changes to nsGenericFactory.cpp went in last night. I'd vote for adding another flag to nsModuleComponentInfo to specify eager factory construction. I'll close this bug and leave it up to Brendan to decide who will own the new one.