HiveMind simply makes a few different choices, with its own set of advantages and disadvantages. There's no IoC, and various bits are /way/ more dynamic than is desireable in an IoC environment. Looking past all the "features" and "history" of both frameworks, this, IMO, is the actual big difference.
We need an industry standard definition of IoC then.
indeed! I'll babble a bit more, see if we can converge on some common ground....
As I understand it, IoC means that a container is responsible for instantiating services, managing them, configuring them, connecting them together, and providing some amount of lifecycle support.
Here's the terminology as avalon pioneered it (much narrower scope):
Inversion of Control -- means exactly what it says: that your components are all set up completely from the top down (or from the outside in in the container-component view).
This has farreaching consequences when universally applied. A component is only allowed to do what it is told. It is not normally allowed to do anything else, like look things up on its own (through JNDI for example, or any other kind of registry).
That's it. IoC is not about lifecycle management, instantiation management, configuration, or anything like that. It's a concept.
Okay, but what do you tell a component to do? That is where instantiation, management, composition, configuration, logging and similar aspects can come into play. All of those are concerns (among others) that /can/ exist in the relationship between container and component.
Avalon makes the choice to draw big black lines between each of those concerns, and encode those choice rather bluntly and intrusively into interfaces, and hence, into all "avalon components". This leads to a distinct component lifecycle. Avalon also makes the choice to enforce seperation of API and implementation (components can only access other components through interfaces), and several others.
But all that doesn't /have/ to exist to call it IoC, nor is anything said about the complexity of the container-component contract, nor is anything said about which concerns that the container manages for a component. For example, PicoContainer is definately all about IoC, but it doesn't support any of the management, configuration, or logging concerns that avalon and hivemind do try to address, therefore it doesn't need any kind of lifecycle either.
The only two things pico supports is composition (providing a component with its dependencies) and configuration (providing a component with user-designated runtime state). To achieve that, it does have to handle component instantiation as well, but tries to offload as much of that as possible to adaptors. You might see Pico as "pure"/"minimal" IoC with everything else stripped out.
----
Now, you can /use/ HiveMind for an IoC setup. The big difference with avalon is that you can just as easily use HiveMind for a non-IoC setup. HiveMind itself (disclaimer: gathered from just a few quick glances at the sourcecode) also isn't totally saturated with IoC. Thus, HiveMind is more like "component glue" (much like Spring framework, which is remarkably similar on the surface).
To IoC or not to IoC is left up to the HiveMind user. Right?
OTOH, If you don't buy into IoC, you won't buy into Avalon.
----
> Outside of lifecycle support, HiveMind has all of that, mostly via > the BuilderFactory.
And this is something where we perhaps should attempt to foster some interoperability. Avalon-Fortress has a component factory concept; so does Pico (though they call it adapter now), so does hivemind. Figure out a way to share these factories cross-container and we might be halfway there.
Of course, interoperability is not a sexy job; it is much more fun to code from scratch. I have been known to start from scratch several times a week.
----
I might summarize that as "Avalon is a very rigid kind of component framework, HiveMind acts a lot more like component 'glue'".
I always like glue. Smells funny!
<marketing-hat>s/HiveMind/DuckTape/</marketing-hat>
Close enough; added a few changes (large documenats are a pain in a Wiki, however, perhaps this should be split into multiple pages?)
volunteering? ;)
http://lsd.student.utwente.nl/jicarilla/RelatedProjects
SoC IoC SAI DecP and AOP-lite HiveMind's geek code!
hey, that's a wiki too! Meaning you're free (actually obliged according to http://lsd.student.utwente.nl/jicarilla/Welcome_20to_20the_20documentation_20team) improve on its contents :D
cheers!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
