Inert markup still needs an engine to process those markup. That'll take time to review. As I
said, the elegant generic-ized mechanism is more complex than just "hacking it and getting job done".
Refactoring a giant simple method into 3 smaller simple methods may not need much review effort.
Not a lot of change propagation required. Ie, we don't need to hunt down all of OFBiz for codes
that call the giant method.
It's just about object-oriented programming or simple abstraction. Yeah, it's IT terms, not
biology. I'm looking to study varsity-level Chemistry and jump to molecular biology right now, by
the way! Curious. :)
Say the giant method is named "GiantMethod". Say there are 100s of areas in OFBiz that calls
GiantMethod. We won't need to affect those 100s of areas. How?
We retain the GiantMethod's signature. We take out GiantMethod's insides, and split them into 3
separate methods named "SmallMethodA", "SmallMethodB", and "SmallMethodC". We rewrite GiantMethod
to call those 3 smaller methods.
The review effort is small. We just need to make sure that the new GiantMethod still functions
exactly the same as the old GiantMethod.
Your custom codes can now call on any combination of the 3 separate methods.
You know, maybe we can help each other. You get me into the bioengineering field, and I'll do what
I can for you in the IT field. What say you? :)
Jonathon
Chris Howe wrote:
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
