APEL version

[Keiichi Suzuki]

>>>>> apel-ja の No. 00070
>>>>> Message-Id: <htxk8nrvrm9.fsf ＠ mulelab3.etl.go.jp> で、
>>>>> "守岡" == tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko)さま曰く...

守岡> この問題に関しては product-provide するような場所で、要求する product
守岡> を検査するのが良いかなと思います。つまり、継承する親 product の満たす
守岡> べき制約を書けば良い訳です。

はい。これもありますが、それとは別に...

一般に同一の product を構成する複数のファイルがロードされる場合、あるファ
イルの version と他のファイルの version が異なるという状況は異常なものと
考えられることが多いと思います。

こういうものを検出するための手段をあらかじめ定義しておくと便利ではないで
しょうか?  ただ、プログラムの作成中や、どうしてもこういう使い方をしたい
という要求もあるかも知れませんので、このチェックを抑制する手段も必要だと
思います。

また、 product に関するチェックのためのコードをいちいち、 
product-provide の周辺に書くのは面倒なので...

1. product-add-cheker() の様なものを設けて、 product 構造体のなかに追加
   する。

2. product-define() の中で、既存の product であれば、そこに登録されてい
   るチェック用関数を呼び出すようにする。
   ;; 依存している product をチェックするために product-run-checker() と
   ;; いうのも必要だと思います。

3. (各 *.elc に product 情報を埋め込むとして) product-provide() は、
   define-product() を呼び出すようなコードを生成する。

このようにするのであれば product-provide() ではなく、 
product-define-feature() として、(provide FEATURE) の部分と分けるという
のはどうでしょうか?

Elisp 的に (provide FEATURE) が Top level にないというのは、人によっては
違和感を覚えるのではないかという気がします。また、 check 用関数でエラー
を発生しても、小林さんのような書き方の場合、先に (provide FEATURE) され
てしまうのもうれしくないような気がします。

既に古いバージョンがインストールされている状態で、コンパイル時にエラーを
発生しては困りますが、この辺をどうクリアするかは考えていません。

;; 「やりすぎ」という意見もありそうなのと、コンパイル時の動作を完全に理
;; 解していませんので、コードは書いていません。 ^^;;;;

;;;; 試行錯誤する時間がないので... 済みません。

守岡> もっとも、圭一さんの方法の方が記述の点では楽ですね。product の 
守岡> data 構造を変えれば product を利用する *.elc を作り直さないといけ
守岡> ないのが難点ですが。

構造が根本的に変ることはないと思っています。(変えてはいけない性質のもの
だと思いますし。)

もし何か情報を追加するのであれば vector を長くすれば良いと思いますし、将
来のコードでは、過去のデータ構造を考慮したものにすれば良いのではないでしょ
うか?

ところで、 product-find() はこのようなものではまずいでしょうか?

(defun product-find (product)
  (cond
   ((stringp product)
    (product-find-by-name product))
   ((featurep product)
    (product-find-by-feature product))
   (t
    product)))

;; このようなものでよければ、 product-find-by-(name|feature) はなくして
;; しまっても良いように思います。
-- 
鈴木圭一 / keiichi ＠ nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B