cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Fri, 27 Sep 2002 20:05:43 GMT
Giacomo Pati wrote:
> Ok, this thread had made alot of people think about it and the conclusion
> is that we should not switch to a newer/better container at least until a
> 2.1 release is out, right?
> I've allready commited the step 1 (Loggable -> LogEnabled).
> Now I'm on step 2 (as there has not been any -1). This can be done while
> we stay with ECM for now and have still backward compatability for all
> custom Components somebody has around for his private projects.
> But I have some questions about this move. We have classes named after
> the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd
> like to hear your suggestion how we should deal with those:
> 1. don't change the names
> 2. rename them to appropriate names like CocoonServiceManager
> 3. create new one and deprecate the old ones
> What is your oppinion?

The CocoonComponentManager et. al. are internal classes that are used in
the core.  They can be altered safely without breaking client code.  The
ComposerAction OTOH is something that a client may have extended to
write their own Actions.  In that case you *have* to do the deprecation
and new version.

My suggestion is to determine whether the class is really meant to be
used by users of Cocoon.  That would include the abstract classes to
implement new pipeline components.  If it is an internal component,
then you can easily change it without repurcussion.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:
For additional commands, email:

View raw message