本文由 简悦 SimpRead转码， 原文地址 flylib.com
AppleScript： The Definitive Guide, 2nd Edition,2006, (isbn 0596102119, ean 0596102119), by Neuburg M......
21.1. 脚本附加功能的利弊
脚本附加功能在实现功能的同时也提供了访问功能的术语。可编写脚本的应用程序也是如此。那么，为什么要使用脚本附加功能而不是可编写脚本的应用程序呢？显然，脚本附加程序在某些方面比可编写脚本的应用程序做得更好。应用程序必须运行才能成为目标；如果没有运行，就必须找到它，这可能需要用户干预，而且必须启动它，这需要时间。但脚本附加程序一旦安装，就会一直存在。如果脚本附加程序提供了某个界面，那么该界面就会成为当时所针对的应用程序的一部分。应用程序的字典必须加载（使用告诉块或术语块）才能访问其术语；而脚本附加程序的术语只是语言的一部分。因此，可编写脚本的应用程序不能用来定义事件处理程序的术语。而且，与应用程序通信要比调用脚本附加命令慢（尽管比以前慢）。
另一方面，在某些方面，脚本添加显然是件坏事。这里有一些内存管理方面的考虑，但技术性太强，不便在此赘述。脚本附加功能使用起来很不方便，因为脚本附加功能不仅要存在于用户的机器上（就像可编写脚本的应用程序一样），还必须安装在特定的位置。脚本添加可以定义强制，但这些强制不能记录在字典中。最后，脚本附加功能会侵入 AppleScript 的全局命名空间，这可能会造成混乱和令人沮丧。脚本附加功能可能与程序员希望使用的术语相冲突；如果编译脚本时脚本附加功能存在，而运行脚本时却不存在，那么脚本可能会被破坏，而且原因可能难以追查。(有关示例和进一步讨论，请参见第 20 章）。
基于上述原因和其他原因，Apple 通过言行积极阻止脚本附加功能的扩散。其中包括以下官方声明： "在脚本附加功能方面，你能做的事情会受到严重限制，而且管理大量脚本附加功能的系统成本很高。(苹果公司在这里提到的主要限制是脚本添加不能定义任何类。我引用的苹果文档还指出，脚本附加功能不能在调用之间保持状态，但这已不再适用）。
这些事迹包括苹果公司自己逐渐放弃使用脚本附加程序，代之以可编写脚本的应用程序（可能是不露脸的后台应用程序）。在 Mac OS 9 中，Scripting Additions 文件夹中默认的 9 个文件中有 5 个是应用程序；在 Mac OS X 中，/System/Library/ScriptingAdditions 文件夹中的 7 个文件中有 5 个是应用程序。(在 Mac OS X 下，/System/Library/ScriptingAdditions 文件夹中有 7 个文件，其中 5 个是应用程序。因此，把这些应用程序放在这个文件夹中，是确保它们存在的一种方式，同时也暗示它们履行了与脚本附加功能类似的实用功能）。
尽管如此，脚本附加功能历史悠久，并没有很快消失的迹象。在 AppleScript 诞生的早期，开发者热情地提供免费或共享的脚本附加程序，用户收集这些附加程序的热情接近于 HyperCard 用户收集 XCMDs 的热情。(一个广受欢迎的权威脚本附加库是 www.osaxen.com ）。添加脚本是一种方便的方式，可以为 AppleScript 提供系统级的能力和快速计算能力，而这些能力和能力是 AppleScript 所缺乏的。它们是 AppleScript 生活中不可或缺的一部分。
