From: stephan b. <st...@s1...> - 2005-05-26 13:43:25
|
On Wednesday 18 May 2005 16:28, Prochnow, Christian wrote: > 1) The first problem was that using Phoenix<> inside of a template > leads to different instances used by client- and library-code. We > should keep that in mind - never use Phoenix<> inline or inside of a > template !! Doh?? i've never seen this problem in s11n, and i've used that approach since well over a year. > 2) The second problem was the FactoryInstanceHook code. I wondered > why Factory::create() could not create a type which should be ... > remember, the goal was that Factory can create types that are > dynamically registered by shared libraries, without even knowing > about shared libraries. Good :). The Hook thing was weird, and i wasn't really happy with it. > 1) Instances of Factory are now kept by the FactoryBase class, which ... > requested Factory > (Factory::createHook()). Sounds cool :). > A draw-back is that the new Factory implementation does not support a > variable key-type, since it is not possible for the non-templated > FactoryBase to have variable key-types. Maybe we can re-introduce > this feature, if it's really needed, by using key-string's generated > by LexT<>. That's a rarely-used feature, in my experience. i use it sometimes for mapping enum entries to types, but it's certainly not critical. > We now have an instance of the FileLogTarget class which got > dynamically registered by the shared-library, cool .. isnt it ? > > With the old Factory and PluginManager code clients had to be aware > that FileLogTarget did come from a plugin and therefore had to use > PluginManager<LogTarget>::create() instead of > Factory<LogTarget>::create(). i'm almost 100% certain that that's a side-effect of the Hook, not the Phoenix. i'm glad you changed the way that worked, anyway. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |