On 02/08/17 20:18, João Paulo Lemes Machado wrote: > When you talk about the cost, do you mean backward compatibility?
The time taken to do it, the duplicated code until the deprecated code can be removed, the cost of downstream users updating their code. All for a minimal maintenance benefit. Overall, that isn't something I'm interested in pursuing. That doesn't mean someone else won't be interested. Just that I'm not. Mark > > > 2017-08-02 4:38 GMT-03:00 Mark Thomas <ma...@apache.org>: > >> On 02/08/2017 00:02, João Paulo Lemes Machado wrote: >>> Hi Mark. >>> >>> Did you take a look at my suggestion? >> >> Yes. I don't think the cost is worth the benefit. >> >> Mark >> >> >>> >>> 2017-07-25 15:33 GMT-03:00 João Paulo Lemes Machado < >> lemesmach...@gmail.com> >>> : >>> >>>> Hi Mark, tanks for the comment. >>>> >>>> Let me take the DataSourceProxy as example. >>>> >>>> This class has 142 methods of which 112 are get () and set () methods. >>>> We could mark these methods as deprecated and copy them to a new class: >>>> DataSourceProxyConfig, but we would leave them in the DataSourceProxy >> class, >>>> and they would be removed gradually. >>>> >>>> Those parameters and methods would be accessed by an instance variable >> of >>>> DataSourceProxyConfig in DataSourceProxy. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> >>>> And if for some reason we can not make these changes (remove the >> methods), >>>> this strategy can be adopted to prevent these classes from growing even >>>> more. It can also be adopted as a new practice for creating new classes >> in >>>> the future. >>>> >>>> >>>> What do you think? >>>> >>>> >>>> >>>> >>>> >>>> 2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>: >>>> >>>>> On 25/07/17 13:55, João Paulo Lemes Machado wrote: >>>>>> Hello everyone. >>>>>> >>>>>> My name is João Paulo, I am a graduate student the Federal University >> of >>>>>> Uberlandia, Brazil. >>>>>> >>>>>> I was analyzing the modularization of some classes of Tomcat, and I >>>>>> identified some opportunities for cohesion improvement in the >> following >>>>>> classes: >>>>>> >>>>>> DataSourceProxy >>>>>> ConnectionPool >>>>>> BasicDataSource >>>>>> DelegatingCallableStatement >>>>>> PoolProperties >>>>>> PoolConfiguration >>>>> >>>>> Those look to be from a mix of implementations (Commons DBCP and >>>>> Tomcat's jdbc-pool). >>>>> >>>>> This is the place to discuss changes to Tomcat's jdbc-pool. DBCP >> changes >>>>> should be discussed on the Apache Commons dev mailing list. >>>>> >>>>>> Could you please take a look and tell me if it's viable? >>>>> >>>>> Hard to comment without a concrete example. >>>>> >>>>>> Maybe some of these classes could benefit from some kind of >> refactoring >>>>>> that we can discuss. >>>>> >>>>> Maybe. What did you have in mind? >>>>> >>>>> Mark >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>>>> >>>>> >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
