我怀疑这是风格和/或个人品味的问题,但我想我还是会问.
我一直习惯于定义包:
(defpackage :wibble
(:use :cl :drakma)
(:export :main))
一旦我执行了IN-PACKAGE(在这种情况下是wibble),我就可以使用DRAKMA中的符号:
(http-request ...
然后我最近读到经验丰富的Lisp黑客不愿意:使用但是:
(drakma:http-request ...
只是想知道意见的共识是什么,以及是否有任何利弊(不是那种类型的CONS :))？
干杯,
彼得
Xac*_*ach 13
当你use使用软件包时,如果使用的软件包发生变化,可能会有一些微妙的方法.
首先,该包可能在将来导出更多符号.例如,如果包导出一个新符号library:rhombus并且您已经使用它myapp::rhombus来命名,那么您突然使用继承符号,包含所有可能的附件(例如类,defuns,宏等),有时会产生奇怪的结果.如果您使用合格的符号名称,则不会获得任何符号或任何小于您想要的符号.
其次,包可能会在将来停止导出符号.因此,例如,如果library:with-rhombus消失,您的调用(with-rhombus (42 42 42) ...)将突然出现无效函数调用的错误,(42 ...)而不是直接指向问题源的东西,即"缺失"符号.如果使用合格的符号名称,则会出现错误,Symbol WITH-RHOMBUS is not exported from the LIBRARY package其中的行更清晰.
导入符号(带:import-from或:shadowing-import-from或import)并非没有问题.导入适用于任何符号,无论它是否为外部符号.因此可能是现在符号的情况library::rhombus,即不再用于公共消费,但导入仍然可以正常工作而没有错误.
您使用哪个选项取决于您对源包的舒适程度.你是否控制它,如果没有彻底的测试,你不会做出任何相互矛盾的改变？继续导入或使用您心中的内容.否则,在库包接口更改时,请注意检查意外的副作用.
这更像是一个风格问题,所以不可能将它分类为黑白,但这里有利弊:
使用包限定符号.
避免符号冲突.
允许清楚地区分外来符号.
允许轻松搜索,替换,复制......使用外部库中的某个符号(用于重构,将代码提取到其他地方等)
使代码更加丑陋,但仅限于库名太长时.(例如,我的昵称添加re到cl-pprce了,现在使用的代码它甚至更好,比W/O型资格:想re:scan)
导入整个包
基本上,与前一案例相反.但我倾向于将它与实用程序库一起使用,因为使用限定名称通常会使其代码更加简洁明了:)
:import-from package symbol
这是您忘记提及的一个选项.我认为,当您经常使用某个包中的一个或非常不同的符号时,它可能会有用.它还允许导入未导出的符号.
到目前为止，很好的答案。
另一种观点认为，包装及其符号构成一种语言。如果你认为一个符号应该是这种语言的一部分，那么你应该使其可用，而不需要与其他包限定它-编程时，在这门语言。
例如，在CLIM实施中，有一个CLIM-LISP软件包可以设置实施语言。它是COMMON-LISP软件包的变体。然后是诸如CLIM-SYS（资源，进程，锁等），CLIM-UTILS（Common Lisp的各种实用程序和扩展）和CLIM本身的软件包。现在，在新的软件包SILICA（抽象窗口系统）中，使用了这四个软件包。因此，二氧化硅的实现是用一种语言实现的，该语言是两种语言的结合体（Common Lisp变体CLIM-LISP和CLIM的UI命令）以及两个实用程序包，这些实用程序包通过某些功能扩展了CLIM-LISP。
在上面的示例中，使用这些包是有意义的，因为它们相互扩展以形成新的语言，并且该新包中的实现大量使用了这些包。
如果您有一个需要冲突的软件包的软件包，那么使用它们就没有意义了。例如，程序包可以使用为GUI量身定制的绘图命令并用于Postscript输出。他们将有相似的名字。两者都使用会导致冲突。您还希望在源代码中为这些符号来自何处的人类读者清楚。它是来自脚本或GTK +库的画线命令吗？如果您可以轻松找到它，那就太好了-即使函数名称相同。