Functions Example

[chris25]

The whole setup is basically easy now to understand, the relationship between the function and the handler and what is actualy going on inside the engine. But one puzzle remains unclear in Jacque's example:

function addNumbers num1,num2
put num1 + num2 into theTotal
return theTotal
end addNumbers

on myHandler
put field "firstNum" into theFirstNumber -- say the field contains 16
put field "secondNum" into theSecondNumber -- say this one is 4
put addNumbers(theFirstNumber,theSecondNumber) into field "sumTotal"
end myHandler

The handler includes the function that will do some work - it adds two numbers together. But the names of these two variables inside the handler, by all rational logic, (theFirstNumber,theSecondNumber) should really be (num1,num2), How on earth does the function establish what to add up when the two variables that IT contains are different from the two Variables that the handler has. This is hard to see why this works. I would have expected to have had the variables belonging to the Function to be identical to the variables that possess the numbers temporarily stored within them, that are inside the handler.
chris

[andrewferguson]

Hi Chris,
The data passed to a function can be in any container and does not have to be the same as used in the function.
So, for example:

Code: Select all

on mouseUp
   ask "Number to square?"
   answer square(it)
end mouseUp

function square numberToSquare
   return numberToSquare*numberToSquare
end square

LiveCode will take whatever data that you want passed to the function (in this case the variable it), and then put it into the variable that the function requires (in this case numberToSquare).
So you could pass any form of data to this function, from a field, variable, or even from a file. It does not matter, LiveCode will take it and pass it to the function.

I hope this helps.

Andrew

[dunbarx]

Chris.

Oh. Having fun eh? Impressed with LC, eh?

What Andrew alluded to in answering your question might be rephrased this way:

1-The parameters sent when you call the function can be named in any way you wish, as you know.
2- The parameters listed in the function handler itself can also be named in any way you wish, as you still already know.
3- The mapping from one to the other is strictly by passed order. So if you have:

- get yourFunction(AAA,BBB,CCC)
and
- on yourFunction XXX,YYY,someVeryDescriptiveName

LC will map the "CCC" to the "someVeryDescriptiveName", because, simply, they both come third. The naming in either case may have its own natural description guidelines, and may only make sense within each one's own environment. You will see this soon when you call a function from many different handlers, where those handlers have their own parameter naming requirements, but the called function works those parameters in one specific way.

Homework: look up "param", "the params", "the paramCount". You might appreciate the power that these give you, especially when you do not know explicitly what, and how many, parameters you might have. You are already familiar with the ability to use a property in place of an explicit value in, say, a repeat loop:

repeat with y = 1 to the number of lines of fld "yourField"

Really powerful. These new words should fall into the same category of usefulness. And, if you are really ambitious, read up about passing parameters by reference as well as by value.

More Homework. After all, it is a Sunday. Ever passed parameters from one handler (not a function) to another:

on mouseUp
doSomething param1,param2,param3
end mouseUp

on doSomething xxx,yyy,zzz

Craig

[chris25]

Thankyou Andrew, although I must say that Craig's elaboration cleared up a vital point of confusion, that the passed order is what LC is reading, not mapping (in this context) name to name but position to position as I understand things right now. This really is both a 'wow', and an 'unbelievable gasp'. No wonder I was i such turmoil before trying to understand what Jacque had written along with all the scripts I was reading, in one sense I think maybe it seems a pity that names can be different, at least from my in-experienced perspective, because had the names had to have been identical between handler and function variable then this surely would be a point of ease and consistency in the writing of script. I think?

Yes Craig I will be looking up the things you mentioned, thankyou both though.

[dunbarx]

Chris.

It is comforting to have the same names now and then, but probably will not stay so when, as I said, you have calls originating from several places:

Code: Select all

function areTheseEqual  firstArg,secondArg --pretty dry-sounding names, no?
  return firstArg = secondArg
end areTheseEqual

called from, say:

answer areTheseEqual(17,13)
answer areTheseEqual(the length of fld 1, the textFont of fld 1)
answer areTheseEqual("true",areTheseEqual(500,500))

The whole point of being able to separate these handlers, whether function or command types, is to create what used to be called "subroutines", mini library code gadgets that are available from everywhere. They often reside in stack scripts or higher. You will want to make these when, say, in a long handler, you find yourself dong a mini-task over and over. You will find these situations soon.

Oh yes. What do you think about that third example?

Craig

[chris25]

Ok I see now, three functions all the same name but returning different arguments/different calculations is disaster. Third example? spent some time looking at it, but really, I am not that knowledgeable really to know even where to comment. By looking at "true", being that it is surrounded by quotes I would imagine that it is a text string, and therefore in a text box? ( I know it could be an object if surrounded by quotes, but in the context of the word itself I have assumed it to be text); 500,500 well this seems to be not two figures really but one co-ordinate? Thereby the answer would be False? and I suppose everyone is laughing right now, but I gave it my best shot based on only what I know rather don't know yet.
Kind regards
chris

[dunbarx]

Chris

Yes, "true" is a string. Everything is a string. Parameters are always separated by commas. What on earth is a "text box"?

Not three functions. One function called three times.

Third example?

500,500 well this seems to be not two figures really but one co-ordinate?

answer areTheseEqual("true",areTheseEqual(500,500))

Think about it step by step. We have a function call with two parameters as with all the others, "true" and a second parameter which, it happens, is a full-fledged function call with its own two parameters ("500,500"). This is evaluated BEFORE the primary function call is made. This is a fundamental rule with these sorts of things. Once this is done, the primary now reduces to:

answer areTheseEqual("true","true") --which yields "true".

See?, the secondary function call is merely the second parameter to the primary function call. Maybe this was too soon too fast.

Anyway, write some of these whether you need to or not.

Craig

[chris25]

Yes right, now it is clear. But you see I had no idea that the 500 500 was a function inside that function. Oh a text box, I meant a text field, but still keep referring to it as a text box - a habit ingrained since 'birth' - from my use of adobe illustrator and photoshop.

I suppose actually I just did not see that third example as a function within a function, still trying to grasp the grammar of an alien language - not that clever at spotting the obvious because well I guess I still ned to re-train my eye. It is easy when you are younger, if you are brought up in a certain way of thinking/training, it's like laying a foundation on fresh soil. But I keep having to tear down mental concepts before I can build new ones, I just don't see the bloody obvious so easily. It's taking time:)
regards
chris