Thanks, Craig. I think there might be a misunderstanding. See within.
On Mon, 29 Nov 2004 18:32:06 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 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" ...
> }
>
So far the comparison is this: IoC creates the implementation of the
Bar class with configuration and so on at startup. There has to be a
class somewhere, of course, which is the implementation that IoC plugs
into the app. HaD just starts with this class sitting where the
implementation class is supposed to be. Your class might be called
"BarTypeXImpl". My class is always called "BarImpl" merely.
So far, all HaD requires none of the considerable coding overhead
required by dependancy injection. (I hope I don't sound negative
about lightweight, IoC containers, because I am not. Just looking
around here.)
Now, if you want to change the implementation class to, say,
"BarTypeYImpl", you have to change the configuration and restart the
application. I just drop call this new implementation by the same
name ("BarImpl") and drop it in place of the old implementation.
Then, I call BarHotFactory.loadBarImpl(). The result is that the Bar
class reference and the Bar classloader class reference are changed to
the new BarImpl. There will be no straggler references to cause
garbage collection problems, I now see.
> Now, in your scheme you upgrade the Bar class (of course, setting up a
> new class loader to contain it).
This only happens when there is a change. The IoC has also to do something.
> 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.
This is, I think, mistaken. Isn't it? The class reference content
has changed. The reference Bar has to a classloader and the reference
Bar has to a class remains the same but points to a different entity.
Right? So, when Foo no longer uses Bar, Bar will be garbage
collected. The sole result that is of significance is that Bar has
been updated but the Bar in Foo is using the old version. Right? All
new Bars created in Foo will be the new version. All new Foos will
create new Bars. Right?
If we want all client Foos to use the newest and greatest Bars, we can
do so by restarting the application. This is the same thing we have
to do with IoC, or we can get a solution for HaD that wil mirror any
solution for IoC. So, the sole problem is that HaD can do things that
IoC cannot do. You don't have to do that. Correct?
>
> 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.
>
> * 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.
>
> 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.
Jack
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
