Just a lurker; I'm trying to follow along but I still don't get it.
Dakota Jack wrote:
You can tell me to use "create on demand" instead, but then I don't need anything fancier than an IoC framework that lets me reconfigure on the fly.
And, current IoC approaches provide me other important benefits:
* Multiple implementations can be used without the user having to know the implementation class name.
This is shared by IoC and HaD.
Not really. If you only have BarHotDeploy then you can only create one type of Bar, yes? I could have a different versions of Bar used in different contexts. BarDatabaseImpl, BarXmlImpl, whatever. A config file could match these up as needed.
* Don't need the artificial confusion of multiple instances of the same class name.
I am not sure what this is referring to, Craig. You can do this or not do it. It is not necessary.
Except now I'm confused. So far the only benefits you seem to tout are hot-deploy and lack of configuration. But hot deploy will necessarily leave multiple version of BarImpl hanging around. Any old Foo objects will still be holding their old Bar reference. So if you don't restart the app you could have (n) versions of BarImpl hanging around logging what they log and doing what they do. Kind of confusing.
With the use of dynamic proxies you could mitigate this since you could create a proxy that would forward calls on to whatever real current object exists. Then all Foo has is a Bar dynamic proxy implementation.
I'm still not sure that hot-deploy on a single class basis has any lasting value, though.
For those reasons alone, I'm satisfied sticking with current IoC approaches, and have sort of lost interest in pursuing this any further.
I just thought I would address these and leave it up to you whether or not your interest was rekindled by these considerations, given especially that you said "sort of". ;-)
Thanks again for the conversation. Interesting.
From my perspective, I kept hoping it was something deeper, but (no insult intended at all) it just kept seeming like someone figured out how to marry the factory pattern with a classloader. Much more interesting classloader magic has been done in the Eclipse internals, for example.
-Paul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
