On Mar 22, 2006, at 7:34 AM, Rob Cozens wrote:
Hi Geoff,
-- breaking out routines for local vs. server connection
You're ignoring my notes: application requirement: the calling
syntax must be identical for client, server, and single user.
That's fine -- I'm just saying that the routine would look something
like:
on doSomething pArg
if tSingleUser then
doSomethingForSingleUser pArg
else
doSomethingForMultiUser pArg
end if
end doSomething pArg
This way the user can call the routine without regard to whether it's
single user or multiuser, but you don't have two big chunks of code
lumped together in one handler that can easily be separated.
-- breaking out a routine for when we're just counting records
that match vs. returning data
Why? It is not used anywhere else but in this handler. Like Chipp,
if I find a need for the logic in another handler, I'll generalize it.
Because it gets rid of a bunch of if statements in your repeat loop.
It costs you a bit in that the repeat structure is duplicated in the
routine that simply counts, so that's a tradeoff. But your repeat
ends up being faster because you aren't doing tests each time through.
Further, your code ends up being easier to understand, because one
routine simply counts, while one returns data -- more clear.
-- breaking out a routine that, given a itemList describing a set
of fields, returns the data from those fields
Why? It is not used anywhere else but in this handler. Like Chipp,
if I find a need for the logic in another handler, I'll generalize
it. And actually, theSDRecordMatches function handles most of that
logic.
Just because something isn't used anywhere else doesn't mean it
should be lumped in. If it can be clearly expressed as a single
action (given an itemList describing a set of fields, return the data
from those fields) it can be broken out, and both routines will be
easier to understand as a result.
to me a routine like this is more than five times as difficult to
understand/debug/manage than the five twenty line routines that
might replace it.
Where's the beef! Show me the money! Divide findSDRecord into
five twenty-line routines and post the result.
I must say, Geoff, you seem to have a penchant for splitting
handlers when there is no need to do so.
I obviously don't know SDB well enough to:
-- know what's right for it by my standards
-- know what's right for it by your standards
-- change code (or propose changes) in it without knowing the
context in which the code operates
I thought a bit before offering comment. Maybe not long enough ;-) If
I've offended, I apologize. It wasn't my intention to cast stones at
anyone's house in particular.
If you can indulge me for just a moment longer, though, I'd like to
throw out an analogy. Look at your comments above. The same thing
could have been said as:
On Mar 22, 2006, at 7:34 AM, Rob Cozens wrote:
Hi Geoff, You're ignoring my notes: application requirement: the
calling syntax must be identical for client, server, and single
user. Why? It is not used anywhere else but in this handler. Like
Chipp, if I find a need for the logic in another handler, I'll
generalize it. Why? It is not used anywhere else but in this
handler. Like Chipp, if I find a need for the logic in another
handler, I'll generalize it. And actually, theSDRecordMatches
function handles most of that logic. Where's the beef! Show me the
money! Divide findSDRecord into five twenty-line routines and post
the result. I must say, Geoff, you seem to have a penchant for
splitting handlers when there is no need to do so. Rob Cozens CCW,
Serendipity Software Company "And I, which was two fooles, do so
grow three; Who are a little wise, the best fooles bee." from "The
Triple Foole" by John Donne (1572-1631)
Breaking up your comments into paragraphs doesn't change the meaning
of what you said, but it makes it clearer.
regards,
Geoff
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
