Stephen McConnell wrote:
Vadim Gritsenko wrote:
...
Why deprecating this interface in the first place? I don't see how presence of (non-deprecated) Component interface may impose limitations on Avalon's future.
Its a massive obsticle.
Imagie you are dealing with code that has nothing to do with Avalon - your building real components - but the only difference is that they don't implement org.apache.avalon.framework.componet.Component (which contains no method declarations or static declarations - nothing). This means that any component developed outside of the Avalon sphere of influence is not a component. That is unreastic and irratrional. This means that the hunreds of standard compoents (refer OMG work) are nbot realy components. This means that unless I incorporatye this particular interface I cannot interoperate in a Avalon framework. That's what is wrong with Componet - it locks you into Avalon. The truth (and the reason for the Service4 package) is that you don't need lock in - you need liberty.
Cheers, Steve.
I kind of understand this part about bringing non-avalon components into Avalon, and also I don't completely agree with this (without further thinking), my question was a bit about different thing. Your argumentation can justify redefenition of "Avalon Component" term to include all Objects. But why deprecate all existing Avalon Components (now you have to go and fix'em all and fix all your containers which expect Component - Cocoon's case) by deprecating Component interface? I mean, you can extend definition of component and include all this non-Avalon thingies out there (if you see that it's possible and adds value), but this by itself does not require deprecation of Component interface. Which means, there is something more to it...
Vadim
(someone who belives that lockin is a bad thing)Vadim
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
