Nicola Ken Barozzi wrote:
Stephen McConnell wrote: ...
Honestly - I think its a bad thing to do. Deprecation is something that can be formally applied at a Java source file level and inforomally defined on other artificats (configs, etc). I would prefer this sort of thing to be managed at the CVS level in conjuntion with appropriate build procedures. If you tag something in CVS as a 1_X branch, then under that a 1_1 branch, and things get deprecated - when you do the 2_X branch - that's the point where the deprecated content dissapears. By introducing a xxx/classic and xxx/compat your basically moving the notion of branching out of CVS and into the file structure.
This is not what I intend.
In 1.0 I have a class.
In 1.1 i deprecated it and move it in the src/deprecated dir.
In 2.0 I remove the deprecated stuff.
The benefits in 1.1 are that I can be *sure* that the core package doesn't need the deprecated classes to compile, that the users understand better that they are deprecated, and that users that want to not use deprecated stuff can do so without having the deprecated stuff in the classpath.
This works when you have a relatively clean seperation - e.g. building framework without the component package is a viable proposition. However, if you look at the logkit scenario you have non-deprecated class that are referencing depricated classes. Which means that deprecated classes need to be brought back into the standard java/src in order to build. I.e. the strategy breaks because of the non-deprecated referencing depricated cases.
Look at Cocoon, we cannot build a Cocoon without dozens of deprecated classes. This means that deprecation has been totally inefective.
Actually I think there is a darker problem underlying all of this. When we do "COP" we design with an ever present notionof service verus work interface. When we think about changing things, I've seen several cases of changes that maintain the service interface but break the inheritance based usage. Based on the problesm I am seeing related to COP usage - I'm moving in favour of component classes being declared final, but backed by a non-final abstract class. The reason is that making promises relative to inhertence is a totally different subject relative to maintaining a service contract.
Clearly things in the file structure tend to be easier to manage - but at the same time I think it has a bunch of hidden problems. Test cases in one example, but what about configurations, property files, etc. At the end of the day I think that this comes down to better management of CVS tags and synchronizing builds against tagged content.
Hmmm, probably you don't get the point, see above. The simplest thing is to do the following: 1) compile the source 2) compile the deprecated classes with (1) in classpath 3) use the two packages combined in all following steps In this way you get the separation benefits without additional problems.
Assuming there are not deprecated classes referenced in you main src tree. (and that's a big assumption) Cheers, Steve.
I understand what your aiming at - just not convinced about the approach ;-)Yeah, that's why it's a proposal. ;-)
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
