When I've used globals, I've always defined them at the top of the script.
I can then use them in a handler later.
For instance:
global dd_mmm_yyyy set dd_mmm_yyyy to (do shell script ("date \"+%e-%b-%Y\"") as text)
my showDate()
on showDate() tell application "Finder" to display dialog dd_mmm_yyyy end showDate
So unless showDate was in a library, the global doesn't need to be defined within tge handler.
As a programming practice, I try to NEVER write a handler I expect to move to a library that depends on something that is defined outside the handler. If I need something inside the handler that is established by the calling routine, I pass it in through the parameter list (again, I'm an old school programmer... I learned on Fortran in the early 70's).
Thus the above script would become:
global dd_mmm_yyyy set dd_mmm_yyyy to (do shell script ("date \"+%e-%b-%Y\"") as text)
my showDate(dd_mmm_yyyy)
on showDate(DateToShow) tell application "Finder" to display dialog DateToShow end showDate
So, I still don't understand why I need/want to use a property at all. It seems that variables can be used for just about anything.
I guess the only other distinction (although a very significant one) that I failed to mention earlier is the initial property value is evaluated (and applied) at compile time whereas a variable isn't evaluated until run-time.
So this is valid:
property f_ScriptSrc : "HD2:Script Source:" property f_LibSrc : f_ScriptSrc & "Libraries:"
and this is valid:
set f_ScriptSrc to "HD2:Script Source:" set f_LibSrc to f_ScriptSrc & "Libraries:"
but this is not:
set f_ScriptSrc to "HD2:Script Source:" property f_LibSrc : f_ScriptSrc & "Libraries:"
Jim
I don¹t think so, the only scoping differences are:
You must declare globals inside handlers to access their value, but not Properties; when you run a script object and declare a global with the same name as a global in the script, the script object has access to the global declared in the script. That is not the case in properties.
|