On 2017-07-23, João Paulo Lemes Machado wrote: > Analyzing the points of our discussion, I have realized that the most > critical problem is the dependence these classes may have on other classes.
> With that in mind I recommend a gradual refactoring that works as follows: > First, we mark the methods we want to extract as depreciated. > Then, we copy those methods to a new class. > So we will keep the methods in the original class for some time so that > developers who have some assumption about the class can adapt. > For example, the Javadoc has 114 methods, of which 64 are get () and set () > methods. We could mark these methods as deprecated and copy them to a new > class: JavadocConfig, but we would leave them in the Javadoc class, and > they would be removed gradually. > Those parameters and methods would be accessed by an instance variable > in Javadoc. > However, when choosing the methods we could analyze their complexity. If it > is a simple set () or get () that only sets or returns a value it would be > prioritized. > Methods that have a greater complexity, or that make calls to other methods > would not be extracted at first. > What do you think about this strategy? This strategy is a sound strategy if you expect users of your API to follow releases closely. Unfortunately this is not what we see with Ant. Right now we are fielding a bug reported by somebody who is migrating from Ant 1.6.2 to 1.10.1 - 1.6.2 has been superseeded by 1.6.3 in 2005. This is not uncommon. People are using additional libraries like ant-contrib. ant-contrib has seen its last release in 2010 and it's development has stalled completely. We cannot remove any method used by it at all without breaking build files of people who rely on ant-contrib. Unfortunately ant-contrib is not the only example. This has led to us never removing any methods at all, no matter how long it has been deprecated. I'm not sure this is a good idea and not saying it has to stay that way, but the above has been the rationale for it. To be honest, I am one of the people who've upheld the "backwards compatible at all cost" mantra. Part of this may be due to the pain of "every release of Ant breaks my builds" threads around the release of Ant 1.2 (almost 17 years and I still recall it like yesterday, strange). If others feel it is time to revisit our extremely strong and at the same time limiting stance on backwards compatibility, I'll be listening to them. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
