From: stephan b. <st...@s1...> - 2004-12-25 17:37:20
|
Yo, In the last mail i wrote: > class Factory<InterfaceT,[ContextT,?]KeyT,Arg1T> { i thought i'd take a minute and explain why i have all these ContextType template args in the Factory and Phoenix classes. Let's consider this code: T & t1 = Phoenix<T>::instance(); T & t2 = Phoenix<T>::instance(); In this case, t1 == t2. That might be just what we want, but we might want part of an app to have a shared T which isn't seen by everyone else. And we also want the post-main() safety of Phoenix. No problem - we use a context type: struct my_context {}; T & t1 = Phoenix<T>::instance(); T & t2 = Phoenix<T,my_context>::instance(); Now t1 != t2. Any client code who knows the right combination of T and context can get at a Phoenix<T,ctx>. Another implication is that the context allows Factory<T,ctx> to restrict the sharing of factories. For example, if we want the IOManager to use the P-wide shared factories, we use P::Sharing::FactoryContext (the default ctx used by Factory). If we want IOManager to use it's own restricted pool of factories, we can use another arbitrary context type. Using the default FactoryContext is generally a good idea, because it means that registrations which come in via DLLs are available to Factories which didn't open the DLL. The down-side is that if two plugins use the same logical name and same InterfaceT, then we will have a factory collision (in which case we fix it by forcing one of them to use another ContextType). Actualy - if the 2 factories both provide the same behaviour (return new T) then such a factory collision is actually a non-error/no-op. The shared objects served by Phoenix not true singletons because we can still do: T * t3 = new T; They are also not Monostates unless T is designed as a Monostate. i don't really have a good name for this type of shared object, so i call them "context singletons." That is "singletons within a certain context." -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |