Thanks Jonathon for the reply. While breaking giant methods up and refactoring may be the ideal solution, I'm a bit of a realist and understand that approach will never happen in any community project with enough regularity and discipline to not be consistent roadblocks in an external development. The speed at which OFBiz moves in adding features and use cases is too valuable to copy and paste the desired code snippet into a custom application that then has to be maintained wholly by an individual business. If I were to refactor a simple method and delivered a patch right this moment, it would be two to six weeks before someone reviewed sufficiently to ensure it worked as expected. However, if I were to submit a patch that simply added inert markup, no review would be necessary, because it doesn't do anything to OFBiz.
OT: It's interesting to note people's backgrounds and how they think about problems. Jonathon obviously has a java background and is fixated on scope and classes. I have a molecular biology background and the solution that I'm proposing follows the start and stop codon methodology of DNA and protein transcription. It's kind of cool to bounce these ideas off different mindsets. ----- Original Message ---- From: Jonathon -- Improov <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, November 16, 2007 9:37:48 PM Subject: Re: [RFC] simple method subsections Wow, thanks for the detailed explanation! This whole exercise sounds like "breaking up coarse-grained methods into fine-grained decoupled flexible ones". Then it should be nothing more than breaking up a giant simple method into independent pieces that can be reused in many places. Why go through the trouble of creating a new mechanism for "sectioned methods"? (In Java terms, it's like a simple method is a "class", and the sections are like "methods".) Suppose we have a huge method that has 3 sections that seem independent. We break it up into 3 separate methods. That's a refactor. We maintain the 3 separate methods in OFBiz. The 3 new methods can be reused in hundreds of places in OFBiz. Well, if they are reused in only a few places in OFBiz, then we had just done a refactor with bad ROI. Ok, so what if our custom project can reuse the 3 methods in 100s of places, but OFBiz project won't? Then we should do our own custom refactor, and break the giant method up into 3 methods. No point doing the refactor in OFBiz where there's bad ROI. As for overhead caused by "tiny little simple methods each requiring to be wrapped in a service", that'll come back to the problem of Minilang methods not being able to call other Minilang methods in the normal way that common programming languages do. If we come to this problem, we may talk about this more. Jonathon
