6

これは、スタイルや個人的な好みの問題だと思いますが、とにかくお願いしたいと思いました。

私はこのようにパッケージを定義する習慣があります：

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

IN-PACKAGE（この場合は：wibble）を実行すると、DRAKMAのシンボルを装飾なしで使用できます。

(http-request ...

それから私は最近、ベテランのLispハッカーが：useではなく：を望んでいることを読みました。

(drakma:http-request ...

ここで意見のコンセンサスが何であるか、そしてどちらの方法でも賛否両論（そのタイプのCONSではない:)）があったかどうか疑問に思いましたか？

乾杯、

ピーター

4

4 に答える 4

13

パッケージを作成する場合use、使用するパッケージが変更された場合に問題が発生する可能性のある微妙な方法がいくつかあります。

まず、パッケージは今後さらに多くのシンボルをエクスポートする可能性があります。たとえば、パッケージが新しいシンボルlibrary:rhombusをエクスポートし、すでにそれを使用しmyapp::rhombusて名前を付けている場合、継承されたシンボルを突然使用し、可能なすべての添付ファイル (クラス、defun、マクロなど) を使用することになり、奇妙な結果になることがあります。修飾されたシンボル名を使用すると、必要なシンボルより多くも少なくも得られません。

第 2 に、パッケージは将来的にシンボルのエクスポートを停止する可能性があります。したがって、たとえば が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、つまり、もはや公共の消費を目的としていない場合がありますが、インポートは引き続きエラーなしで機能します。

どのオプションを使用するかは、ソース パッケージに対する快適さのレベルによって異なります。あなたはそれを管理していますか? また、完全なテストを行わずに競合する変更を加えることはありませんか? 先に進んで、心ゆくまでインポートまたは使用してください。それ以外の場合は、ライブラリ パッケージ インターフェイスの変更に伴う意図しない副作用のチェックに注意してください。

于 2012-07-30T16:06:27.990 に答える
6

これはスタイルの問題なので、白黒で分類することはできませんが、長所と短所は次のとおりです。

  1. パッケージ修飾シンボルの使用。

    シンボルの競合を回避します。

    外国のシンボルを明確に区別することができます。

    外部ライブラリから特定のシンボルを簡単に検索、置換、コピー、使用できます (リファクタリング、コードを別の場所に抽出するためなど)。

    コードを醜くしますが、ライブラリ名が長すぎる場合のみです。(たとえば、ニックネームreをに追加するcl-pprceと、それを使用したコードは、修飾なしよりもさらに優れています: と考えてくださいre:scan)

  2. パッケージ全体のインポート

    基本的に、前のケースの反対です。しかし、修飾名を使用すると、コードをより簡潔で明確にするという目的全体に勝ることが多いため、ユーティリティライブラリで使用する傾向があります:)

  3. :import-from package symbol

    これは、言及するのを忘れていたオプションの 1 つです。特定のパッケージから1つまたは非常に異なるシンボルを非常に頻繁に使用する場合に役立つと思います。また、エクスポートされていないシンボルをインポートすることもできます。

于 2012-07-30T12:50:29.400 に答える
6

これまでのところ良い答え。

もう 1 つの見方は、パッケージとその記号が言語を構成するというものです。シンボルがこの言語の一部であるべきだと考える場合は、この言語でプログラミングするときに、別のパッケージで修飾する必要なくシンボルを使用できるようにする必要があります。

たとえば、CLIM 実装では、実装言語をセットアップする CLIM-LISP パッケージがあります。これは、COMMON-LISP パッケージの変形です。次に、CLIM-SYS (リソース、プロセス、ロックなど)、CLIM-UTILS (Common Lisp のさまざまなユーティリティと拡張機能)、および CLIM 自体のようなパッケージがあります。現在、新しいパッケージ SILICA (抽象ウィンドウ システム) では、これら 4 つのパッケージが使用されています。したがって、Silica の実装は、2 つの言語 (Common Lisp バリアント CLIM-LISP と CLIM の UI コマンド) と CLIM-LISP をいくつかの機能で拡張する 2 つのユーティリティ パッケージの結合として構築された言語で実装されます。

上記の例では、パッケージを使用することは理にかなっています。なぜなら、それらは互いに拡張して新しい言語を形成し、その新しいパッケージの実装はそれらを多用するからです。

競合するパッケージを必要とするパッケージがある場合、それらを使用しても意味がありません。たとえば、パッケージは、GUI および Postscript 出力用に調整された描画コマンドを使用できます。彼らは似たような名前を持っています。両方を使用すると、競合が発生します。また、これらのシンボルがどこから来ているのか、人間の読者のためにソース コードで明確にする必要があります。PostScript または GTK+ ライブラリからの線描画コマンドですか? 関数名は同じでも簡単に見つけられると助かります。

于 2012-07-30T19:33:01.500 に答える
4

経験則として、私:useは一般的な言語を拡張するパッケージですが、特別なアプリケーションを持つパッケージには修飾記号を使用します。たとえば、私はいつも:usealexandria を使いますが、Hunchentoot の完全修飾記号を参照します。疑わしい場合は、修飾名を使用します。

于 2012-07-30T20:47:43.643 に答える