Making the move...

[Geoff Canyon]

Wow -- so what does this do?

On Mar 20, 2006, at 9:28 AM, Rob Cozens wrote:

> Hi Geoff,
>
>
>> Out of curiosity, do you have an example handy of a long handler  
>> that you think makes more sense to keep together than to break up?  
>> Or one that you think can't be broken up without significant  
>> effort to do it?
>>
>
> on findSDBRecord  
> @sdbBuffer,exactKey,fieldDelimiter,itemList,setPosition,searchForward, 
> searchCriteria,cutoffKey,recordDelimiter,unlockRecord
>   -- 28 Feb 04:RCC
>   if ipcMode is not "dc" then -- "dc" = single user direct connection
>     replace return with numToChar(29) in itemList
>     replace return with numToChar(29) in searchCriteria
>     requestSDBService sdbBuffer,"find",packArguments 
> (9,exactKey,fieldDelimiter,itemList,setPosition,searchForward,searchCr 
> iteria,cutoffKey,recordDelimiter,unlockRecord)
>     get the result
>     if not word 1 of it and setPosition then put word 4 of it into  
> sdbPosition
>     put it into sdbParameters
>     return it
>   else
>     if invalidSDBClient() then return true&return&sdbMessage 
> (sdbInvalidClientError,true)
>     if offset(return&sdbDbId&return,return&(the keys of indexList) 
> &return) = 0 then return true&return&sdbMessage(sdbDbIdError,true)
>     if exactKey is empty then put true into exactKey
>     put (fieldDelimiter is not empty) into retrieveData
>     if recordDelimiter is not empty then
>       put true into multipleRecords
>       put false into unlockRecords
>       put false into setPosition
>     else put false into multipleRecords
>     put (multipleRecords and not retrieveData) into countOnly
>     if setPosition is empty or retrieveData then put true into  
> setPosition
>     if searchForward is empty then put true into searchForward
>     put ((sdbWriteAccess is "Shared") and (unlockRecord is true))  
> into unlockRecord
>     put word 2 to 4 of sdbParameters into savedPosition
>     put justifyString(word 1 of sdbBuffer,4) into theRecordType
>     getSDBRecord sdbBuffer,exactKey,,,setPosition,retrieveData
>     get the result
>     put word 2 to -1 of line 1 of sdbBuffer into recordKey
>     if word 1 of it or (((recordKey > cutoffKey and searchForward)  
> or (recordKey < cutoffKey and not searchForward)) and cutoffKey is  
> not empty) then
>       put false&&savedPosition into sdbParameters
>       put false&&"0 0 0" into line 1 of it
>       return it
>     else
>       if unlockRecord and sdbWriteAccess is "Shared" then  
> deleteDbLock(word 4 of sdbParameters)
>       if not retrieveData and not multipleRecords then
>         put it into sdbParameters
>         return it
>       end if
>     end if
>     put word 4 of sdbParameters into oldPosition
>     put empty into returnRecord
>     put 0 into recordCount
>     repeat
>       put word 2 to -1 of line 1 of sdbBuffer into recordKey
>       if (recordKey > cutoffKey and searchForward) or (recordKey <  
> cutoffKey and not searchForward) then
>         put false into word 1 of sdbParameters
>         if countOnly then
>           put empty into sdbBuffer
>           return (word 1 to 3 of sdbParameters)&&recordCount
>         else
>           put theRecordType&&recordCount&return&returnRecord into  
> sdbBuffer
>           return (word 1 to 3 of sdbParameters)&&"0"
>         end if
>       end if
>       delete line 1 of sdbBuffer
>       if theSDBRecordMatches 
> (sdbBuffer,fieldDelimiter,searchCriteria) then
>         add 1 to recordCount
>         repeat for each line itemNumber in itemList
>           put sdbFieldNumber(itemNumber) into itemNumber
>           if itemNumber = 0 then put recordKey&fieldBelimiter after  
> returnRecord
>           else put getItem(itemNumber,fieldDelimiter,sdbBuffer) 
> &fieldDelimiter after returnRecord
>         end repeat
>         if multipleRecords then put recordDelimiter after returnRecord
>         else
>           put theRecordType&&recordKey&return&returnRecord into  
> sdbBuffer
>           return (word 1 to 3 of sdbParameters)
>         end if
>       end if
>       set cursor to busy
>       if searchForward then
>         if word 2 of sdbParameters < word 3 of sdbParameters then
>           put "+" into sdbBuffer
>           getSDBRecord sdbBuffer,exactKey,,,true,retrieveData
>           put the result into sdbParameters
>         else put true into sdbParameters
>       else
>         if word 2 of sdbParameters > 1 then
>           put "-" into sdbBuffer
>           getSDBRecord sdbBuffer,exactKey,,,true,retrieveData
>           put the result into sdbParameters
>         else put true into sdbParameters
>       end if
>       if word 1 of sdbParameters then
>         put false into word 1 of sdbParameters
>         put oldPosition into word 4 of sdbParameters
>         if countOnly then
>           put empty into sdbBuffer
>           return (word 1 to 3 of sdbParameters)&&recordCount
>         else
>           put theRecordType&&recordCount&return&returnRecord into  
> sdbBuffer
>           return (word 1 to 3 of sdbParameters)&&"0"
>         end if
>       else if not setPosition then put oldPosition into word 4 of  
> sdbParameters
>     end repeat
>   end if
> end findSDBRecord
>
> Note:
> 	stack local variables and constant declarations excluded.
> 	application requirement: calling syntax at server and client apps  
> must be identical...
> 		and identical with single user syntax
>
>> When you think of a long handler, do you generally think of it as  
>> having a single identifiable task, or do you think of it as being  
>> several tasks performed in sequence in one handler?
>
> I think of it as a task handler coordinating and calling on the  
> various subtasks necessary to complete the entire logical transaction.
>
> I write one-line handlers too, if the logic is to be used in  
> several places:
>
> on mouseTrapOn -- 3 Mar 04:RCC
>   insert the script of field "Mouse Trap" of card 1 of stack  
> "Serendipity_Library.rev" into front
> end mouseTrapOn
>
>
>>
>> On Mar 19, 2006, at 3:57 PM, Chipp Walters wrote:
>>
>>> Yep, I've heard that before, but frankly, for me, I'd rather keep  
>>> it all in one, unless there's a really good reason to separate  
>>> into multiple handlers (as in creating more reusability). I find  
>>> it much easier to debug code I've written this way than hunting  
>>> through the message path for the 15 or so functions/handlers I've  
>>> written trying to make things 'more simple.' Just a difference in  
>>> coding style.
>>>
>>> In fact, typically I'll write code procedurally in a longer  
>>> handler, then only break it up if/when I know I need to do part  
>>> of the same thing again. Like most of us, I'd rather not code twice.
>>>
>>> Even though, I've got libraries with over 50 handlers/functions.
>>>
>>> -Chipp
>>>
>>> Mark Wieder wrote:
>>>> Geoff-
>>>> Saturday, March 18, 2006, 1:24:50 PM, you wrote:
>>>>> I've never seen a hundred-line routine that wouldn't be better as
>>>>> five twenty-line routines, each of which could be documented  
>>>>> with a
>>>>> line of code. Perhaps even ten ten-line routines.
>>
>>
>
> 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)
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>