The long answer on when to use a function vs command
Thomas McGrath III
3mcgrath at adelphia.net
Wed Mar 15 10:13:01 EST 2006
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
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)
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
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:
> 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.
More information about the Use-livecode