在Code中使用package-name:symbol还是在A DEFPACKAGE中使用:use :package-name更好？

Question

我怀疑，这是一个风格和/或个人品味的问题，但我想我还是要问一下。

我一直习惯于这样定义包：

(defpackage :wibble
  (:use :cl :drakma)
  (:export :main))

一旦我执行了IN-PACKAGE (在本例中为:wibble)，我就可以不加修饰地使用DRAKMA中的符号：

(http-request ...

然后我最近读到经验丰富的Lisp黑客不愿意:使用但是：

(drakma:http-request ...

我只是想知道这里的共识是什么，以及是否有任何赞成或反对(不是那种类型的反对:)。

干杯,

彼得

Answer 1

当你use一个包时，如果用过的包发生了变化，有几种微妙的方式可能会出错。

首先，该包将来可能会导出更多的符号。例如，如果包导出了一个新的symbol library:rhombus，而您已经在使用该myapp::rhombus来命名某个东西，那么您会突然使用继承的symbol，并带有所有可能的附件(例如，类、函数、宏等)，有时会产生奇怪的结果。如果使用限定的符号名称，则得到的符号不会多于或少于所需的符号。

其次，包可能会在将来停止导出符号。因此，例如，如果library:with-rhombus消失了，您对(with-rhombus (42 42 42) ...)的调用将突然得到一个错误，即无效的函数调用(42 ...)，而不是直接指向问题根源的符号"missing“。如果你使用限定的符号名称，你会得到一个错误，沿着更清晰的Symbol WITH-RHOMBUS is not exported from the LIBRARY package行。

导入符号(使用:import-from、:shadowing-import-from或import)也不是没有问题。导入适用于任何元件，而不管它是否是外部元件。因此，可能的情况是，该符号现在是library::rhombus，即不再打算用于公共消费，但导入仍然可以正常工作，不会出现错误。

您使用哪个选项取决于您对源包的适应程度。你有没有控制它，在没有彻底测试的情况下，你不会做任何冲突的更改？请继续导入或使用您的核心内容。否则，在库包接口更改时要小心检查意外的副作用。

Answer 2

这更多的是一个风格问题，所以不可能对其进行白纸黑字的分类，但以下是利弊：

使用包限定符号的

1. 。

避免符号冲突。

允许清晰地区分外来符号。

允许轻松地搜索，替换，复制，...使用外部库中的某个符号(用于重构、将代码提取到其他位置等)

使代码更难看，但仅当库名称太长时。(例如，我向cl-pprce添加了一个昵称re，现在使用它的代码甚至比没有限定的更好: think re:scan)

• Importing the a package

基本上，与前面的情况相反。但我倾向于将其与实用程序库一起使用，因为使用限定名通常会超过使代码更简洁、更清晰的:)

• :import-from package symbol的全部目的

这是您忘记提到的一个选项。我认为当你非常频繁地使用某个包中的一个或非常不同的符号时，它可能会很有用。它还允许导入未导出的符号。

Answer 3

到目前为止，答案还不错。

另一种观点认为，包和它的符号构成了一种语言。如果你认为一个符号应该是这门语言的一部分，那么在用这门语言编程时，你应该让它变得可用，而不需要用另一个包来限定它。

例如，在CLIM实现中，有一个CLIM-LISP包，用于设置实现语言。它是COMMON-LISP包的变体。然后还有诸如CLIM-SYS (资源、进程、锁等)、CLIM-UTILS (各种实用程序和Common Lisp的扩展)以及CLIM本身之类的包。现在，在一个新的包SILICA (一个抽象的窗口系统)中，使用了这四个包。因此，Silica的实现是用两种语言( Common Lisp变体CLIM-LISP和CLIM的UI命令)加上两个实用程序包的联合实现的，这两个实用程序包对CLIM-LISP进行了一些扩展。

在上面的示例中，使用包是有意义的，因为它们相互扩展以形成一种新的语言，并且新包中的实现大量使用了这些包。

如果你有一个需要冲突包的包，那么使用它们就没有意义了。例如，包可以使用为GUI和Postscript输出量身定做的绘图命令。它们会有相似的名字。同时使用它们会导致冲突。您还希望在源代码中为人类读者清楚地说明这些符号来自何处。它是postscript还是GTK+库中的线条绘制命令？如果你能很容易地找到它，那就太好了--即使函数名是一样的。