我刚从 TCL 开始，并试图了解如何最好地定义和集成模块。似乎在包+命名空间概念上投入了很多精力，但据我所知，interp 对于每一个可以想象的场景都更强大、更精简。特别是当涉及到隐藏和重命名程序时，全局命名空间中也缺少蠕变。使用包+命名空间的唯一原因似乎是因为“从前 Sun 这么说”。
我什么时候应该使用包+命名空间而不是 interp？
【问题讨论】：
interp 或namespace 是不明智的。一般情况下，interp 创建一个由主 interp 管理的从解释器。每个 interp 都有自己的命名空间。因此，您可能会通过创建 interps 来浪费资源。但是你的需求应该决定你使用什么。
标签： tcl
命名空间和包一起工作。口译员是另一回事。
命名空间是 Tcl 中的小规模命名上下文。它可以包含命令、变量和其他命名空间。您可以通过本地名称 (foo) 或限定名称 (bar::foo) 来引用命名空间中的实体；如果限定名称以:: 开头，则它与（解释器）全局命名空间相关，并且可用于从解释器中的任何位置引用其命令或变量。 （FWIW，TclOO 对象系统广泛构建在命名空间之上；每个对象都有一个命名空间。）
包是由某种库提供的一堆代码的高级概念。包具有抽象名称（名称不必须与库的实现在磁盘上的存储方式相对应）和不同的版本；如有必要，您可以要求特定版本，尽管大多数时候您不会打扰。包可以通过多种机制实现，但它们几乎都归结为sourceing 一些 Tcl 脚本和loading 一些 DLL。几乎所有包都声明了命令，并且通常鼓励它们将这些命令放在与包具有相同通用名称的命名空间中。但是，由于各种原因，相当多的旧包没有这样做，主要是为了与现有代码的兼容性。
解释器是 Tcl 中的安全上下文。默认情况下，Tcl 创建一个解释器（如果它在wish 中设置控制台窗口，则添加另一个）。一个解释器中的命名实体与另一个解释器中的命名实体完全不同，但有一些关键例外：
频道在所有解释器中都有通用名称。这意味着口译员可以谈论另一个口译员拥有的频道，但仅仅能够提及其名称并不能授予访问该频道的权限。 （stdin、stdout 和 stderr 频道默认共享。）
interp alias 命令可用于生成别名命令，这样在一个解释器中调用命令（别名）会导致另一个解释器中的命令（实现）被调用，所有参数安全地通过了。这允许一个解释器公开它希望另一个解释器访问的任何特殊调用而不会失去控制，但这些命令的实现取决于这些命令是否安全地处理这些参数。
安全解释器是一种默认情况下会分析出 Tcl 的不安全命令的解释器。 （例如open、socket、source、load、cd 等）创建安全子解释器的父解释器可以使用别名机制来添加所需的功能；它非常类似于 OS 系统调用，只是您可以轻松地创建自己的特定于应用程序的调用。
Tcl 的线程包旨在创建每个线程一个解释器（并且别名机制不能跨线程工作）。这意味着默认情况下共享资源的方式很少，线程间通信是通过队列消息传递来完成的。
通常，每个解释器最多需要一次包，并且建议您使用这些包来访问大多数第三方功能。命名空间相当轻量级，可用于各种事情，解释器被认为是昂贵的；许多相当彻底的生产级 Tcl 脚本只能与单个解释器一起使用。 （线程甚至比解释器更昂贵；最好将您创建的线程数与您希望施加的硬件负载相匹配，可能通过使用合适的线程池。）
【讨论】：
模块的目的是提供模块化代码，即可以在模块编写者的知识和控制范围之外被应用程序轻松使用的代码，并且封装了它们自己的内部结构。
基于包命名空间和解释器的模块在封装方面可能同样出色，但要使基于解释器的模块能够很好地与任意应用程序配合使用并不容易（当然有可能）。
我自己的观点是解释器是应用程序级别的（我主要将它们用于用户输入和受控评估），而不是模块级别。命名空间和包都有它们的缺点，但在大多数情况下，它们会以最少的麻烦做他们所期望的事情。
我的建议是，如果您是为了自己的利益而编写模块并且解释器为您提供良好的服务，请务必使用它们。如果您编写的模块供其他人使用，可能包括您自己在 18 个月后使用，您应该坚持使用命名空间和包。
【讨论】：