|
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
|