[ http://issues.apache.org/jira/browse/JAMES-509?page=comments#action_12413314 ]
Steve Brewin commented on JAMES-509: ------------------------------------ For me, this is a prime example of why people have said we need to discuss first, achieve consensus, then act. I'm afraid I don't understand why this wasn't discussed first on the lists. Is it something we need to do? What is the motivation for such a major refactoring? We all know that major changes are prone to creating new issues. What functional issues are being solved? Are they of sufficient importance to outweigh the risk of destabilisation such a radical change engenders? What additional features are provided? The argument for change seems to be "Current FetchMail code is really hard to read and manage". Others have commented how well structured it is (I don't have time to look up the references). This is a matter of style. I'm biased as I refactored the original code into the structure you see now and added a heap of functionally. I don't want to get into an argument about style or how virtuous having "removed 2200 lines of code (50Kbytes of code)" is. I think that the changes are so radical that we are in effect replacing the current implementation of fetchmail and need to ask why? Unlike when I refactored it, it isn't broken and no new features are added so we are not satisfying any user requirements. In making these changes, without even a safety net of unit tests, we are destabilising a component for no more than a matter of style. To me, this doesn't seem wise. There are no obvious benefits that outweigh the risks. -- Steve > Cleanup/Refactor FetchMail code > ------------------------------- > > Key: JAMES-509 > URL: http://issues.apache.org/jira/browse/JAMES-509 > Project: James > Type: Improvement > Components: FetchMail > Versions: 2.4.0 > Reporter: Stefano Bagnara > Assignee: Stefano Bagnara > Fix For: 2.4.0 > Attachments: fetchmail-refactoring1 > > Current FetchMail code is really hard to read and manage. > I loose too much time looking around its code to understand how things works. > So I put my hands in, and applied a few refactoring. > I already removed 2200 lines of code (50Kbytes of code) while keeping the > same functionality (only refactorings). > Of course refactorings like this are not always an easy change: I also remove > the StoreProcessor/FolderProcessor/MessageProcessor granular creation by > refactoring them to top level reentrant objects that take things to process > as arguments to their "process" method. > MessageProcessor is still a mess, but I think this is more selfdocumenting > than before. > I can clean up things much more and update documentation and so on, but I > would like to know if this kind of update is welcome or not, before loosing > too much time. > Stefano -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
