The long answer on when to use a function vs command

[Thomas McGrath III]

Ken, Jac, Andre, and Phil,

In the past I have only used functions for mathematical equations and  
not much else. I tend to use commands(handlers) for everything.

I didn't know about the 'send in time' issue with functions, thanks  
Andre.
I didn't think about the noun usage which seems sound.
I usually considered functions to be small little things but am not  
sure if that is fair or right.

I am curious as to any other unique aspects that could affect a  
decision on which to use in different situations.

Functions are normally used with a 'put' or 'get' -- Is this true?
Commands are normally used alone (with/without a parameter) but not  
usually with a get or put -- Is this true?

Is one more friendly with a lot of parameters? -- enough params that  
you would need a switch/case

If you have a function to get some info on an object like:
put getObjInfo("objName") into field "Info"

Would you use a command to set that info like: -- or should this be a  
function too? -- (ignore the cust prop aspect for now)
setObjInfo "Fun"

or

getObjVis() -- function
setObjVis true -- command

getObjPosition() -- function
setObjPosition 34,5 -- command


Is get and set a good indicator of wether they should be functions or  
commands?

Thanks

Tom

On Mar 15, 2006, at 1:39 AM, Phil Davis wrote:

> Hi Tom,
>
> Here are some simple ways I figure out whether to use a command or  
> a function in a given situation.
>
> A function name can naturally take on the role of a noun in a  
> sentence. Or in RunRev terms, it can naturally fill the role of a  
> containerName. A good function name can really improve the  
> readability of the code in those places where it is used.
>
>   put selectedTunes() into fld "tuneList"
>   put cardObjectIDs("firstCard") into tObjectList
>   if errorCount() > 3 then...
>
> In each of the above cases, a function name takes the place of a  
> subprocess that is probably secondary to the purpose of the calling  
> handler. That secondary code is moved to a place of its own, where  
> it can be appreciated for its value instead of cursed as a  
> distraction, as it might be if it were coded inline. Without  
> functions, code would be a lot harder to read.
>
>
> A command name can be a short imperative sentence without the spaces:
>
>   refreshMembersList
>   closeCurrentScreen
>   startMotor
>   moveRobotArm "left",5 -- this one has 2 parameters
>
> If at a given spot in your code, you can describe what needs to be  
> done in a short sentence like the ones above, a command will  
> probably serve well in that spot.