avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Re-precating (?) classes (was: RE: What is a Parser?)
Date Mon, 03 Feb 2003 14:44:21 GMT
Nicola Ken Barozzi wrote:
 >
 > Berin Loritsch wrote:
 >
 >> Nicola Ken Barozzi wrote:
 >>
 >>  >
 >>  > Berin Loritsch wrote:
 >>  >
 >>  >
 >>  > What about all the client code that checks for Component and won't
 >> find it in the Cocoon components, and the ones that extend Cocoon
 >> components?
 >>
 >>
 >> It won't break compilation.  Cocoon component interfaces extend the
 >> (Component) interface so all the clients have to do to release is
 >> m_manager.release(foo);
 >
 >
 > You lost me here.
 >
 > We want to remove depecation warnings. Or we remove @deprecated, or we
 > remove Component from the Cocoon component interfaces.
 >
 > If we do the latter, as Vadim points out, this is not going to work for
 > our users:
 >
 > Component c = ((ComponentSelector)manager.lookup(Generator.ROLE +
 > "Selector")).select("something");
 >
 > Basically all the code that casts to Component will stop working.
 >
 > I'm trying to see all the tradeoffs.
 >

Not if we create a proxy.

The ECM and FOrtress et. al. will continue working.


The Component interface is added at runtime, and the Composable
interface is supported by creating a proxy that implements the Component
interface.

Do a little experiment.


1) Upgrade the ECM used in Cocoon.
2) Remove the "implements Component" from the Generator interface.
3) Run Cocoon.

BAM!

It still works.

_It has already been taken care of_


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message