When assigning the current application to a property for coding efficiency purposes, I’ve always used the following form (I happen to use || as the property name, but any variable name will do, of course):
property || : current application
I notice that many users use:
property || : a reference to current application
Is there an advantage to adding a reference to as opposed to leaving it out?
I understand how a variable’s value can be changed by making a reference to the variable and changing the contents of the reference. However, when the reference points to the current application, I can’t see a reason why one would want to change the reference’s contents to a different value; otherwise, the reference would no longer be pointing to the current application. (Apologies if I am not explaining myself better.)
‘current application’ and a reference to it are essentially the same thing:
set fred to current application
set bert to a reference to current application
fred is bert --> true
I suspect that people who use ‘a reference to current application’ do so either to err on the safe side or because they’re influenced by the code refactoring offered by the full version of Script Debugger, which can give ridiculous declarations like:
property NSRegularExpressionSearch : a reference to 1024
Nigel, that’s wonderful information. Thank you for the clarification on a point that I had wondered about for a long time.
Being new to ASObjC, this is an interesting thread for me. I’ve read and understand the above posts–the topic of which is making a reference to “current application”.
As part of my learning, I was studyiing Shane’s PrefsStorageLib.scptd script and noticed the following at the top of the script:
property NSUserDefaults : a reference to current application's NSUserDefaults
property |NSURL| : a reference to current application's |NSURL|
Is there some benefit to using a reference to a class, such as NSUserDefafults?
Using Nigel’s test, the situations may not be the same, though. The results on my computer:
use framework "Foundation"
set fred to current application
set bert to a reference to current application
fred is bert --> true
use framework "Foundation"
set fred to current application's NSUserDefaults
set bert to a reference to current application's NSUserDefaults
fred is bert -- false
Hi peavine.
The purpose of ‘a reference to’ is to get an object specifier (eg. ‘something of something’) rather than the object itself. This can be useful if the specification later applies to another object and you want to use it for that object rather than the original (such as ‘window 1 of application “Blah”’), or if the object can’t be accessed for some reason at the time you need to set a variable to it. The values of properties are set when a script’s compiled, so with these it may be desirable to use ‘a reference to’ to specify something that’ll be on the running machine rather than setting a actual value from the compiling machine.
Values like the enum ‘current application’ and the integer 1024 are concrete values rather than specifiers, so setting a variable to ‘a reference to’ one of them is the same as setting the variable to the value directly.
For the most part, a variable set to a specifier can be used exactly like the specifier it contains. But when comparing for equality, the contents of a variable containing a specifier aren’t the same as the object itself. So fred isn’t equal to bert in the second half of your test script.
Hope this makes sense. 
Nigel. Thanks for the explantion and I think I understand. Would it be somewhat analogous to the reason the first test in the follow repeat loop returns false.
repeat with anItem in {"a"}
anItem is "a" --> false
(contents of anItem) is "a" --> true
end repeat
Yep. That’s exactly right.
To be the results same, need additional coercion
use framework "Foundation"
use framework "Foundation"
set fred to current application's NSUserDefaults
set bert to (a reference to current application's NSUserDefaults)'s class
fred is bert -- true
So, in the Peavine’s example bert is object, but fred is class of this object
Current application is also an object, but as you can see, there is no such confusion with it.
Apparently, AppeScript is smart enough in this case to figure out that you need an object, not its class.
The NSUserDefaults class is the object here. fred is the class and bert is a specifier that can be used to obtain that class. It gets a bit confusing when mixing AppleScript with Objective-C as the two types of result aren’t shown the same way in editors’ Result panes.
The standard way to “dereference” a variable that’s been set to ‘a reference to’ something is with the ‘contents’ operator, although coercions are sometimes used when the occasion demands.
fred is bert's contents
Normally, of course, you wouldn’t use both ‘a reference to’ and something to dereference it in the same command.