On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> I am not sure what you mean by "transparently swap". IoC requires
> fairly extensive configuration for this "transparency". I don't see
> what is transparent about the IoC setting of an implementation at all.
> Am I missing something?
If I use "create at startup", I'm going to get my instance of a
service class configured with its own dependencies. For example, if
I'm using constructor injection:
public class Foo {
public Foo(Bar bar) {
this.bar = bar;
}
... code that uses "bar" ...
}
Now, in your scheme you upgrade the Bar class (of course, setting up a
new class loader to contain it). But what you haven't done is
notified my Foo instance that you should somehow update the private
"bar" variable to point at a new instance based on the new class
(possibly having to do some sort of state transfer as well) ... it
continues to use the old one -- with the side effect that the old one
will not get garbage collected either.
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.
* Don't need the artificial confusion of multiple instances of the
same class name.
For those reasons alone, I'm satisfied sticking with current IoC
approaches, and have sort of lost interest in pursuing this any
further.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
