Re: [pclasses-devel] Rewrite of Factory and PluginManager

[stephan b. <st...@s1...>]

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