cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: What is a Parser?
Date Thu, 30 Jan 2003 01:56:37 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message