In that case I have no reason to not always include it in my standard script setup. It will now be:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use framework “AppKit”
use scripting additions
Any objections?
The only real drawback is that it adds a lot of terminology to code-completion (as in more than doubling the amount). But otherwise it’s probably no worse than including use scripting additions just in case.
I was categorically told (off) by Apple Engineering about this: don’t include any use statements that are not required in the script at hand.
And I was chided for including use scripting additions rather than wrapping use with using terms from 
In the real world, I reckon there are worse things to worry about — and particularly leaving them out when they should be included.
I just spent the last 20 minutes trying to find the correspondence (to no avail) as I can’t remember the exact reasons why they said this (I remember the tone, though…let’s say the bedside manner leaves a bit to be desired).
As best as my buggy CerebralOS can remember, it was along the lines of not introducing unnecessary dependencies, possible name clashes, unknown bugs. i.e., nothing specific, just general good coding practice.
It’s certainly best practice. But I think some allowance needs to be made for the target user base. For example, NSAttributedString is in Foundation, but it also has methods in AppKit.
I guess the issue here is that someone — and this isn’t the first time or place I’ve seen this — has suggested they can leave use statements out because it worked for them. If the alternative is to err the other way, that seems to me to be likely to be less troublesome in the long run.
Oh, and I was also chided for using PDFKit instead of Quartz. Maybe we can just use Cocoa 
(For lurkers, I’m only joking about using Cocoa.)
That’s a bit rough! ASLG’s coverage of use scripting additions says: “If a script uses use scripting additions, AppleScript may optimize scripting addition commands, sending them to the current application instead of the current target (it) when it does not change the meaning to do so. […] Without a use scripting additions command, AppleScript must use a less efficient dispatching scheme, so explicitly declaring them is recommended.” — while at the end of using terms from it says: "using terms from scripting additions does not enable optimization of scripting addition commands as use scripting additions does."
Hmm, I don’t want get into an argument about it, but no, that wasn’t the tenor of the reply I got from Apple. It was more the contrary: include use framework statements only when they’re needed; if you don’t need them, you’ve no business putting them in.
This (to my mind) is the same advice as not importing a framework you don’t need into a Cocoa app, or not importing unnecessary modules into a python script.
FWIW, I think it’s good advice; I just didn’t happen to like the way it was delivered.
But it’s not as bad as it sounds, because the optimisation is only required in code targeting an application, and such code won’t generally compile inside a using terms from scripting additions block anyway.
One of the differences, though, is framework stuff is cached. If you launch with the environment variable ASDebugLibraryLoads set, you’ll see when you run a script with a use framework statement, it’s loaded the first time, and from then on it’s only referenced (speaking on a per-app basis).
I agree with you in principle. I just think it’s a minor issue in the scheme of things.
Thanks to all for this excellent discussion about use statements.
To Shane’s point, I think it makes a difference whether you are writing code for a client to use in a production environment, or in writing code for yourself (and maybe a few friends/colleagues) to use in your/their personal Mac.
It also depends on the type of scripts you will be writing. I’m at the point where many, if not most, of my scripts will directly, or via handlers/script libraries, use ASObjC.
So, since Shane has told us:
I feel comfortable in using a standard set of use statements, not knowing for sure if I will need all of them or not. So, I think I will stick with my default setup:
use AppleScript version "2.5" -- El Capitan (10.11) or later
use framework "Foundation" -- this may not be required
use framework "AppKit" -- this may be not be required
use scripting additions
## Some Scripts may work with Yosemite, but no guarantees ##
# This script has been tested ONLY in macOS 10.11.6+
If at some point in the future I find that including one of these that isn’t required causes a problem, then I will adjust accordingly.
FWIW, you will always need Foundation.
Even if I am not using any ASObjC?
Sorry for the confusion — only when using ASObjC.
Hey Folks,
@CJK came up with this on the Keyboard Maestro Forum a while back.
Life got in the way, and I forgot about it until rediscovering it just now.
-Chris
--------------------------------------------------------
# Auth: CJK from Keyboard Maestro Forum
# : Modified by Christopher Stone <scriptmeister@thestoneforge.com>
# dCre: 2019/04/24 20:03
# dMod: 2019/04/24 20:03
# Appl: AppleScriptObjC
# Task: Find the Default Handler Application for a Given URL-Protocol.
# Libs: None
# Osax: None
# Tags: @CJK, @Applescript, @Script, @ASObjC, @Find, @Handler, @Internet, @Protocol, @Web
# URLs: https://forum.keyboardmaestro.com/t/activate-main-browser-which-are-different-on-systems-where-i-use-the-same-set-of-synced-macros/13572/4
--------------------------------------------------------
use framework "Foundation"
--------------------------------------------------------
property currentApp : a reference to current application
property NSWorkspace : a reference to NSWorkspace of currentApp
property NSURL : a reference to NSURL of currentApp
--------------------------------------------------------
set urlType to NSURL's URLWithString:"http:"
set appPath to (NSWorkspace's sharedWorkspace()'s URLForApplicationToOpenURL:urlType) as text
# activate the application named appPath
--------------------------------------------------------