Making the move...

[Geoff Canyon]

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