On Wed, 3 Apr 2002, Berin Loritsch wrote: > Components (in the formal sense) will always be tied to their container.
I don't know what is the 'formal sense' you are talking about, but one of the goals of commons is to create components that are _not_ tied to a container. > The container provides everything to the component. everything. That means > not just the logger. That means that the component is tied to the > framework anyway. And people have a choice to not use this kind of container - the components we write will work in most containers, if a container have a problem with pull model ( Log.getLog() ) - too bad for it. > Commons, Sun, and several other people use the term component in an > informal > sense. A component has a *role* (or work interface) separate from the > implementation. It is tied to a container, which manages it. Commons has > a modular API, and each API group has been given the informal name of > component, which confuses people who see commons' docs and avalon's docs. I certainly hope avalon doesn't have a trademark on 'component' or claims ownership or 'the Right Definition' of the term. > Lastly, trying to mix IoC and static access based systems is like trying > to mix procedural and object oriented programming. It can be done, but it > is messy, confusing, and not maintainable. Each model has its advantages I don't know about IoC, but push and pull models are mixed in most programs and that's a good and desirable thing. If IoC doesn't 'mix', then it shouldn't be used. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
