how many properties and globals are reasonable, if their content isn’t too long ? (separated clearly by numbers, string lists, paths)
loading a script is like to:
Hi!
I would worry more about having a script with too many lines of code before having too many globals and properties. When you get between a thousand and two thousand, errors in compiling begin to show up, and the script starts to feel slow. I would break it in smaller script files.
I’d say (but without being 100% sure) that it would execute and append to the main script, but it would be temporary. AppleScript does not behave like other programming language being a scripting language, so it could be intelligent enough to manage it’s own memory allocation, not sure. But like I said in 1), it would be better for long scripts to do it this way.
It’s been awhile since i’ve played with simple, vanilla AppleScript, but I don’t remember ever having to unload a script. It could be possible, but I don’t think it’s necessary. Remembering that AppleScript does a lot of the heavy and complicated stuff for you (often compromising speed to get there), it probably unloads it eventually. Again, not 100% sure, it just makes sense in my mind if it would.
How long do you think your code is going to be? How complex? Perhaps you could do it in AppleScriptObjC or AppleScript Studio if you are on 10.5 and previous…
Model: MacBookPro8,2
Browser: Safari 534.51.22
Operating System: Mac OS X (10.7)
I don’t know of an upper limit, but I imagine it depends on the total amount of data rather than the actual number of variables. As a rough guide, only use properties for values which need to be preset, or which may need to be edited later in the life of the script, or which need to persist if they’re changed. Globals are generally frowned upon by the programming and scripting communities, so use those as little as possible.
More nearly the former. It’s simply loading a copy of the loaded script’s compiled code into a variable of the main script. Any running or use of the handlers or properties has to be done explicitly by the main script.
If the variable holding the loaded script is local, it and the loaded script will effectually cease to exist when the script or handler it’s in exits. If the variable’s a property, global, or run-handler variable, the loaded script will be saved back to the main script file and will persist as a value over runs of the script. If you don’t want this, the main script can set the variable to something short like “” before it exits. Any changes to the loaded script’s properties, globals, etc. will not persist unless it’s run directly from it’s own file like the main script.
Follow Nigel’s advice, more precise than mine! 
Model: MacBookPro8,2
Browser: Safari 534.51.22
Operating System: Mac OS X (10.7)
Hi Nigel, Hi Leonsimard,
thanks for your responses. Its fine to hear that properties and globals live good inside applescripts. I’ve finished a bigger personal project, which is split in several scripts and loads additional scripts from the main script if necessary. My question arises because I 'm careful to not load too much code inside the main script, which counts ca.1200 lines. The others have roughly half the lines as the former one, so I don’t want an overload for excess using properties or globals, which store some additional data.
I’ve a new question: After how many lines a script needs to be coded as UB application (Xcode?). The scripting language in serous tools changes hugely, as far as I remember. (Applescript Studio, but now i’m on 10.6)
Nigel, I cannot believe that globals aren’t liked: they are so simple and nice to use.
About load/unload: I tried to load another script in a loaded script, just for convenience, not for playing. But seems not to work.
I understood your answers, the third one was really good. thank you.
At last, two really hard questions :lol: (i googled, but found nothing) I got two definitions which i’m unable to decipher; manipulating smart folders. I need to know if they are something relevant or not. Whats:
Well, I’d say when you get to the complexity you seem to be at, I really think it would be advantageous to switch to AppleScriptObjC. Plus, you can add a user interface to it, and easily divide a script into many smaller ones, no loading/unloading or variable to manage.
Granted, switching from plan Appescript to ASOC is a big step, but it’s worth it in the end. With the added bonus of adding Obj-C code to your app for faster processing or access to things that you can’t get with Objective-C, like C.
With Shane Stanley’s book (the only one i am aware of about ASOC), you’ll be ready to go in no time.
Also, with ASOC, you’ll have access to Obj-C methods and probably save a lot of lines of code, thus probably getting a much faster app in the process.
I don’t know about FXScope, sorry. What is it supposed to be? kMDItemGroupId is related to searching for a kind of item, like text file, when dealing with Spotlight. Don’t have much experience with Spotlight, but there sure is resources about it in these forums.
You could probably find more info about Spotlight here:
Model: MacBookPro8,2
Browser: Safari 534.51.22
Operating System: Mac OS X (10.7)
Seems like FXScope is a key in an XML plist file related to spotlight, but what’s its purpose, no idea… sorry!
I should clarify this. Changes to a loaded script’s properties and globals do not persist in the file from which the loaded script came. If a loaded script is saved back to the main script’s file by virtue of being stored in a persistent variable, the latest values of its properties and globals are stored there with it.
I’ve seen them described as “evil”! 
It’s mostly to do with the “need to know” mentality of Object-Orientated Programming: any values a handler needs which it isn’t going to work out for itself should be passed as parameters, the data should be manipulated within the handler’s private scope, and any values it produces for the script should be formally returned to the calling process.
The presence of globals and properties increases the risk that the author of a handler will accidentally or unknowingly use a variable name which is global in the script ” or, of course, that the author of a script will filch somebody else’s handler which contains a variable name he’s chosen for a global. There are other ways round this, such as using different naming conventions for different kinds of variable, explicitly declaring every variable in every handler local (which they are anyway unless there’s a global or property in the script with the same name), or only declaring variables as global within the ordinary handlers where they’re used as such. But the “black box” approach has much going for it. One advantage is that handlers can be debugged solely within their own contexts rather than within the context of an entire script.
I never use globals myself: partly because I’ve accepted the above arguments, partly because I don’t see the need for them when properties have almost the same ” ah ” properties, but mostly because their values get saved back to the script file every time and change its size and modification date, which annoys the hell out of me for some reason. I even avoid run-handler variables by putting the main code in an ordinary handler (which keeps all the variables local and therefore non-persistent) and use properties only where necessary.
But obviously, AppleScript does provide global variables, so their use isn’t actually illegal.
You’re right. in object oriented programming you almost never need globals. A global sits in the runtime environment and a property sits in the script object but there is one situation I like globals. When I need a external script object, like a require or include in other programming languages, and you need ‘header guards’ I use globals. I’m using this for dynamic object hierarchies and still need once instance of the object in my application. I use globals only here because the lack of the require function in AppleScript.
That’s because you get an instance (copy) of the script object. That means every time you load a script object you get a brand new one.
Nigel,
Hm, interestingly facts. Real happenings are always fun and useful to listen. Personally, I use to write the same variable name convention over and over again. I think they don’t interfere with my globals.
So i assume that the globals and properties i use, are unique in my scripts.
.but that’s the nice part of a global. If you use may handlers which need the same global input you do not need to pass any parameters because the info is written into the global (which content you can manipulate whenever you like). A local is weak in comparison, and to be honest, I don’t know a real use for it. And the property is a bit “wooden” for my taste, but its nevertheless, really useful. (in my scripts mostly for paths or lists)
I’m unsure to understand. if I declare and copy another value into my global, their content will change and persist till the next session I start. This isn’t bad in my eyes. I see only an interaction problem between globals and handlers if you tell applications which use commands similar to the set global value content. In such a case, I use to write ‘|export|’, to be sure to not interfere with some application-specific jargon.
for that are locals, in my eyes. Maybe i’m wrong.
To illustrate what I meant:
Global declarations at the top of a script apply throughout the script, except where the variables concerned are explicitly declared local. If the run handler isn’t explicit, the declarations are regarded as lying outside it.
global v
-- on run
handler1()
say "The run handler says " & v
handler2()
handler3()
-- end run
on handler1()
set v to "Hello"
end handler1
on handler2()
say "Handler 2 says " & v
end handler2
on handler3()
local v
say "Handler 3 says " & v
end handler3
When variables are only declared global in certain handlers, their globality only applies to those handlers. But variables used in the run-handler have this restricted globality whether so declared or not.
on run
global v -- Optional.
handler1()
say "The run handler says " & v
handler2()
handler3()
end run
on handler1()
global v
set v to "Hello"
end handler1
on handler2()
global v
say "Handler 2 says " & v
end handler2
on handler3()
say "Handler 3 says " & v
end handler3
Nigel, your concepts are easy to understand.
Till now i never experienced situations like in example two. It looks quite strange to me to declare a global over and over for any handler i need a specific global. The global features get lost in my eyes, if a script dictates such handler-specific restrictions. Then i prefer to declare my variable as simple set variable, or, if the handler gets a bit longer, as a local value.
But, its only my opinion as passionate coder.