From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Apr 15 18:10:41 2002 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 15 Apr 2002 18:10:41 +0900 Subject: luna =?ISO-2022-JP?B?GyRCJEskRCQkJEY2NSQoJEYyPCQ1JCQbKEI=?= (OO & luna =?ISO-2022-JP?B?GyRCPWk/NDxUGyhCKQ==?= In-Reply-To: NAKAJIMA Mikio's message of "Tue, 15 Jan 2002 20:24:36 +0900" References: Message-ID: 守岡です。御無沙汰してます。超浦島フォローで申し訳ありません。（略）中島さん> (1)me インスタンスについて luna-method をコールしたときに、中島さん> luna-call-next-method で dad クラスの luna-test 自身がコールされ、中島さん> (2)再帰的にコールされた dad クラスの luna-test の中の中島さん> luna-call-next-method で初めて grandpa の luna-test method がコール中島さん> される中島さん> ために y が 2 回加算されてしまうようです。中島さん> luna.el の中を色々見ていたのですが、どうも中島さん> luna-class-find-parents-functions で method が見つかるまで、親クラスに中島さん> 遡って method の探索をするためにこのような動作になるようです。中島さん> [質問] 中島さん> (ア)あるクラスの親 class の method はあるが、(親クラスと同じ動作で良い中島さん> から) そのクラス自身の method を定義しないことは OO 的に誤りなので中島さん> しょうか? そんなことはないと思います。中島さん> (イ)(ア)がもし誤りの場合で、親クラスと全く同じ動作で足りる下位のクラス中島さん> の method は一々親クラスと同じ関数定義をして、そのクラスに特化した中島さん> method を設けるのが良いのでしょうか? それとも中島さん> luna-call-next-method を用いて親クラスの method をコールするだけの中島さん> method を設けるのが良いのでしょうか? それとももっと他に良い方法が中島さん> あるのでしょうか? なにもしなければ親クラスの method が継承されると思いますがそれではまずいのでしょうか？ちなみに、luna-call-next-method（その元ネタの CLOS の call-next-method）は「陰に隠された」method を呼び出すために設けられているものだそうです。中島さん> (ウ)(ア)がもし誤りの場合で、下位クラスに明示的な method が定義されてい中島さん> ない場合、una 的に下位のクラスから親クラスの method をコールするの中島さん> を禁止する必要はないでしょうか? CLOS だと多分 method がどれかの class の持ち物であるということにはなってないと思うので、そもそも下位 class の持ち物である暗黙の method として扱われていることが問題であるような気がします。ちょっと手元に CLOS 処理系を用意してないので、どなたか CLOS 処理系で同様の例を実験していただけないでしょうか？ -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Apr 15 18:45:40 2002 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 15 Apr 2002 18:45:40 +0900 Subject: use of qualifiers of a luna method In-Reply-To: NAKAJIMA Mikio's message of "Sat, 19 Jan 2002 11:42:31 +0900" References: Message-ID: >>>>> [emacs-mime-ja : No.00978] にて >>>>> “中島さん”= NAKAJIMA Mikio さま曰く: 中島さん> luna.el で、同名の method につき、異なる qualifier を指定中島さん> して複数回 luna-define-method すると、最後に define した中島さん> method だけが有効になって他が無効になってしまいます。（略）中島さん> 簡単に直せそうだったらやろうかと思ったのですが、中島さん> luna-define-method がそもそも 1 つの qualifier にしか対応し中島さん> ていないので挫折しました。中島さん> luna.el を使い込むにつれ、どうも advice.el の姿と重なって見えて仕方な中島さん> いのですが、advice.el が :before, :around, :after の各 qualifier 中島さん> (advice.el では class と呼ばれている) を併用可能なのに対して、luna.el 中島さん> が上記のように 1 つだけの qualifier が有効でしかも、評価の順が有効な中島さん> qualifier を決めるのは様なのは少し見劣りがするような気がします。中島さん> これについて、改善の予定はあるでしょうか? 微かな記憶を辿ると、もともと qualifier も support しないつもりだった気がします。でも必要なので最小限のものを付けた気がします。そういう訳で、需要があるのなら付けることに賛成します。ところで、qualifier の出典ですが、直接的には CLOS のをお手本にしてます。そして、確か、起源は Flavor に遡るのではないかと思います。[1] によれば Flavor には :before, :after の他に :list, :and, :or, :progn, :append などがあったようです。これらは適用可能な method の集合に対して実行制御と返り値のまとめ方を指定するもののようです。どうもあんまり評判は良くなかったようで、それで :around が出て来たのかなという気も実際の所は知りません。余談ですが竹内郁夫が作った TAO という Lisp ベースの『マルチパラダイム言語』にも Flavor と同様のものがあった気がします。[2] によれば「…など盛りだくさんのメニューが用意されており、（中略）実はどれも実際にはほとんど使われない（元祖 Flavors には意地で使ったという例があるが）。専ら使われるのは :daemon という組合せである。」とあり、:list とか :and とかの類の使用頻度はやはり低かったようです。 [1] 「Lisp マシンのオブジェクト指向プログラミング」bit Vol.17, No.11 [2] 「マルチパラダイム言語 TAO(6) オブジェクト指向(2)」bit Vol.20, No.6 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From ueno ＠ unixuser.org Mon Apr 15 19:09:16 2002 From: ueno ＠ unixuser.org (Daiki Ueno) Date: Mon, 15 Apr 2002 19:09:16 +0900 Subject: luna =?ISO-2022-JP?B?GyRCJEskRCQkJEY2NSQoJEYyPCQ1JCQbKEI=?= (OO & luna =?ISO-2022-JP?B?GyRCPWk/NDxUGyhCKQ==?= In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "15 Apr 2002 18:10:41 +0900") References:

Message-ID: ;; ほとんどちゃちゃですが、 >>>>> In [emacs-mime-ja : No.01004] >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: 守岡さん> CLOS だと多分 method がどれかの class の持ち物であるということ守岡さん> にはなってないと思うので、そもそも下位 class の持ち物である暗守岡さん> 黙の method として扱われていることが問題であるような気がします。守岡さん> ちょっと手元に CLOS 処理系を用意してないので、どなたか CLOS 処守岡さん> 理系で同様の例を実験していただけないでしょうか？ Debian の clisp で実験したところ、中島さんの期待されたように以下の結果になりました。 -------------- next part -------------- [1]> (defclass grandpa () ()) # [2]> (defclass dad (grandpa) ()) # [3]> (defclass me (dad) ()) # [4]> (defgeneric clos-test (person)) # [5]> (defmethod clos-test ((gp grandpa)) (setq x (+ 1 x))) #)> [6]> (defmethod clos-test :around ((dd dad)) (call-next-method) (setq y (1+ y))) #)> [7]> (setq x 0 y 0) 0 [8]> (setq grandpa (make-instance 'grandpa)) # [9]> (setq dad (make-instance 'dad)) # [10]> (setq me (make-instance 'me)) # [11]> (clos-test me) 1 [12]> x 1 [13]> y 1 -------------- next part -------------- ;; 随分昔に clisp-doc の CLOS-guide.txt.gz のサンプルコードだけを差し替 ;; えて LUNA-guide.txt.gz を書こうとしていたのを思い出しました。^^;; -- Daiki Ueno From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Apr 15 19:24:32 2002 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 15 Apr 2002 19:24:32 +0900 Subject: luna =?ISO-2022-JP?B?GyRCJEskRCQkJEY2NSQoJEYyPCQ1JCQbKEI=?= (OO & luna =?ISO-2022-JP?B?GyRCPWk/NDxUGyhCKQ==?= In-Reply-To: Daiki Ueno's message of "Mon, 15 Apr 2002 19:09:16 +0900" References:

Message-ID: >>>>> [emacs-mime-ja : No.01006] にて >>>>> “上野さん”= Daiki Ueno さま曰く: 守岡>> CLOS だと多分 method がどれかの class の持ち物であるということ守岡>> にはなってないと思うので、そもそも下位 class の持ち物である暗守岡>> 黙の method として扱われていることが問題であるような気がします。守岡>> ちょっと手元に CLOS 処理系を用意してないので、どなたか CLOS 処守岡>> 理系で同様の例を実験していただけないでしょうか？上野さん> Debian の clisp で実験したところ、中島さんの期待されたように上野さん> 以下の結果になりました。（略）実験ありがとうございます。御異存のある方が無ければの村田さんの patch を採用したいと思います。 ;; そういえば、luna って結局 class 変数は導入しなかったんだったっけ？上野さん> ;; 随分昔に clisp-doc の CLOS-guide.txt.gz のサンプルコード上野さん> ;; だけを差し替えて LUNA-guide.txt.gz を書こうとしていたのを上野さん> ;; 思い出しました。^^;; ;; おお、是非是非。(^_^) -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From minakaji ＠ osaka.email.ne.jp Mon Apr 15 21:34:31 2002 From: minakaji ＠ osaka.email.ne.jp (NAKAJIMA Mikio) Date: Mon, 15 Apr 2002 21:34:31 +0900 Subject: luna =?ISO-2022-JP?B?GyRCJEskRCQkJEY2NSQoJEYyPCQ1JCQbKEI=?= (OO & luna =?ISO-2022-JP?B?GyRCPWk/NDxUGyhCKQ==?= In-Reply-To: References:

Message-ID: At 15 Apr 2002 18:10:41 +0900, tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > 守岡です。御無沙汰してます。 > > 超浦島フォローで申し訳ありません。どうも本当にご無沙汰です。守岡さんは UTF-2000 でお忙しいので、 semi/flim/apel にはもう関与されないのか、と (嫌味ではなく) 真剣に思っていました。かく言うぼくも個人的な都合から、apel はおろか、lunafied SKK の開発も止まってしまっているので、他人のことは申し上げる立場にありませんが ;-p。 > 中島さん> [質問] > > 中島さん> (ア)あるクラスの親 class の method はあるが、(親クラスと同じ動作で良い > 中島さん> から) そのクラス自身の method を定義しないことは OO 的に誤りなので > 中島さん> しょうか? > > そんなことはないと思います。 > > 中島さん> (イ)(ア)がもし誤りの場合で、親クラスと全く同じ動作で足りる下位のクラス > 中島さん> の method は一々親クラスと同じ関数定義をして、そのクラスに特化した > 中島さん> method を設けるのが良いのでしょうか? それとも > 中島さん> luna-call-next-method を用いて親クラスの method をコールするだけの > 中島さん> method を設けるのが良いのでしょうか? それとももっと他に良い方法が > 中島さん> あるのでしょうか? > > なにもしなければ親クラスの method が継承されると思いますがそれではまず > いのでしょうか？ (イ)が前提としている(ア)のお答えが、「誤りではない」とのことなので、 (イ)についてはマズいことは何もありません。ぼくの問題提起は、子供が継承する親クラスの method が意図に反し、2 回呼ばれるのは妙ではないか、ということだけです。妙でない場合に備えて仮定の質問をいくつかさせていただいたまででございます。 -- 中島幹夫

http://www.asahi-net.or.jp/~gy2m-nkjm/ From minakaji ＠ osaka.email.ne.jp Mon Apr 15 21:36:24 2002 From: minakaji ＠ osaka.email.ne.jp (NAKAJIMA Mikio) Date: Mon, 15 Apr 2002 21:36:24 +0900 Subject: use of qualifiers of a luna method In-Reply-To: References:

Message-ID: At 15 Apr 2002 18:45:40 +0900, tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > そういう訳で、需要があるのなら付けることに賛成します。需要はここ(私め)にありますが、どうも時間と技量が伴なわないようです m(__)m。 -- 中島幹夫

http://www.asahi-net.or.jp/~gy2m-nkjm/ From minakaji ＠ osaka.email.ne.jp Mon Apr 15 21:38:06 2002 From: minakaji ＠ osaka.email.ne.jp (NAKAJIMA Mikio) Date: Mon, 15 Apr 2002 21:38:06 +0900 Subject: luna =?ISO-2022-JP?B?GyRCJEskRCQkJEY2NSQoJEYyPCQ1JCQbKEI=?= (OO & luna =?ISO-2022-JP?B?GyRCPWk/NDxUGyhCKQ==?= In-Reply-To: References:

Message-ID: At 15 Apr 2002 19:24:32 +0900, tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > 御異存のある方が無ければの村田さんの patch を採 > 用したいと思います。是非お願いします。 > ;; そういえば、luna って結局 class 変数は導入しなかったんだったっけ？う～ん、あれば使うかもしれませんが、slot と Emacs の一般の変数で足りるような気もします。 -- 中島幹夫

http://www.asahi-net.or.jp/~gy2m-nkjm/ From ueno ＠ unixuser.org Sat Apr 27 04:38:29 2002 From: ueno ＠ unixuser.org (Daiki Ueno) Date: Sat, 27 Apr 2002 04:38:29 +0900 Subject: LSDB 0.1 Message-ID: <02c445d4-56d4-416a-b09d-775730edc807@deisui.org> FLIM/SEMI と親和性の高い(?) 軽量なアドレス帳 LSDB (The Lovely Sister Database) をリリースします。 http://deisui.org/~ueno/emacs-lisp/lsdb-0.1.tar.gz 現状では、Semi-gnus と Wanderlust 用の設定関数を含んでおり、 XEmacs 21.4.6, Emacs 21.2, Emacs 20.7 上での動作を確認しています。まだ機能は少ないうえにバグが大量に潜んでいると思いますが、興味のある方は試して不具合等を報告して頂けると嬉しいです。 -- Daiki Ueno From shirai ＠ rdmg.mgcs.mei.co.jp Sat Apr 27 16:31:24 2002 From: shirai ＠ rdmg.mgcs.mei.co.jp (Hideyuki SHIRAI (=?iso-2022-jp?B?GyRCR3IwZj0oOVQbKEI=?=)) Date: Sat, 27 Apr 2002 16:31:24 +0900 (JST) Subject: LSDB 0.1 In-Reply-To: <02c445d4-56d4-416a-b09d-775730edc807@deisui.org> References: <02c445d4-56d4-416a-b09d-775730edc807@deisui.org> Message-ID: <20020427.163124.112960210.shirai@rdmg.mgcs.mei.co.jp> こんにちは、白井です。 # emacs-mime-ja には入っていませんので、エラーになるかもしれない # です。(_ _) From: Daiki Ueno さん曰く Subject: LSDB 0.1 Message-ID: <02c445d4-56d4-416a-b09d-775730edc807 ＠ deisui.org> Date: Sat, 27 Apr 2002 04:38:29 +0900 > FLIM/SEMI と親和性の高い(?) 軽量なアドレス帳 LSDB (The Lovely Sister > Database) をリリースします。 (へそ曲がりなので)Mew で試してみました。BBDB と比べてもサクサク動いてすばらしいです。また、試したのは、Meadow-1.15(=Emacs-20.7) です。以下、バグ？及び要望です。 (1) M-x lsdb の buffer で寺西さんの Attribution を消そうと Yuuichi Teranishi の行頭で "d" => "Attribution" をすると、上野さんの Attribution が消えてしまいました。これは寺西さんの方が自然ですよね。 Daiki Ueno Net: ueno ＠ unixuser.org Attribution: DU <== こっちが消えた User-Agent: T-gnus/6.15.6 (based on Oort Gnus v0.06) (revision 03) Yuuichi Teranishi ~ Net: teranisi ＠ gohome.org Attribution: 寺 <== こっちを消したい Creation-Date: 2002-04-27 以下のパッチのようにすれば動きました。 --- lsdb.el.orig Fri Apr 26 23:34:16 2002 +++ lsdb.el Sat Apr 27 16:01:48 2002 @@ -578,10 +578,11 @@ '(lsdb-font-lock-keywords t)))) (defun lsdb-narrow-to-record () - (narrow-to-region - (previous-single-property-change (point) 'lsdb-record nil (point-min)) - (next-single-property-change (point) 'lsdb-record nil (point-max))) - (goto-char (point-min))) + (let ((end (next-single-property-change (point) 'lsdb-record nil (point-max)))) + (narrow-to-region + (previous-single-property-change end 'lsdb-record nil (point-min)) + end) + (goto-char (point-min)))) (defun lsdb-current-record () (let ((record (get-text-property (point) 'lsdb-record))) (2) lsdb-mode-save() のときに y-or-n の質問を抑制できるとうれしいです。今は、hook から呼ぶときに (call-interactively 'lsdb-mode-save) していますが、引数 or 変数の方がうれしいです。 (3) 可能で、かつ、そんなに時間がかからなければで良いのですが、 M-x lsdb で表示される buffer を header で sort してくれるととうれしいです。 -- 白井秀行 (mailto:shirai ＠ rdmg.mgcs.mei.co.jp) こちらの ML の方々には興味ないと思われますが、Mew で必要だった最小限の設定↓ (add-hook 'mew-init-hook 'lsdb-mew-insinuate) (defun lsdb-mew-insinuate () "Call this function to hook LSDB into Mew." (require 'lsdb) (add-hook 'mew-message-hook 'lsdb-mew-update-record) (add-hook 'mew-summary-toggle-disp-msg-hook (lambda () (unless (mew-sinfo-get-disp-msg) (lsdb-wl-hide-buffer)))) (add-hook 'mew-suspend-hook 'lsdb-wl-hide-buffer) (add-hook 'mew-quit-hook 'lsdb-mode-save) (add-hook 'kill-emacs-hook 'lsdb-mode-save)) (setq lsdb-decode-field-body-function (lambda (body name) (set-text-properties 0 (length body) nil body) body)) (defun lsdb-mew-update-record () (let* ((fld (mew-current-get-fld (mew-frame-id))) (msg (mew-current-get-msg (mew-frame-id))) (cache (mew-cache-hit fld msg 'must-hit)) records) (save-excursion (set-buffer cache) (when (setq records (lsdb-update-records)) (lsdb-display-record (car records)))))) (add-hook 'mew-draft-mode-hook (lambda () (define-key mew-draft-header-map "\M-I" 'lsdb-complete-name))) # 動くのは Mew-2.x 以降かしら？ From ueno ＠ unixuser.org Sun Apr 28 13:48:12 2002 From: ueno ＠ unixuser.org (Daiki Ueno) Date: Sun, 28 Apr 2002 13:48:12 +0900 Subject: LSDB 0.1 In-Reply-To: <20020427.163124.112960210.shirai@rdmg.mgcs.mei.co.jp> (Hideyuki SHIRAI =?ISO-2022-JP?B?KBskQkdyMGY9KDlUGyhCKSdz?= message of "Sat, 27 Apr 2002 16:31:24 +0900 (JST)") References: <02c445d4-56d4-416a-b09d-775730edc807@deisui.org> <20020427.163124.112960210.shirai@rdmg.mgcs.mei.co.jp> Message-ID: <9b2e0cfc-ae60-4077-adc7-b6a6fc879acd@deisui.org> >>>>> In [Wanderlust : No.09856] >>>>> Hideyuki SHIRAI (白井秀行) wrote: > > FLIM/SEMI と親和性の高い(?) 軽量なアドレス帳 LSDB (The Lovely Sister > > Database) をリリースします。 > (へそ曲がりなので)Mew で試してみました。 > 以下、バグ？及び要望です。ありがとうございます。 (1) のパッチと Mew の設定をそのまま頂いて、0.2 としてリリースしました。 ;; Mew 2.2 で試してみましたが、うまく動いているようです。 http://deisui.org/~ueno/emacs-lisp/lsdb-0.2.tar.gz 0.1 からの主な変更点は以下の通りです。 * の白井さんのパッチと御意見を取り入れた。 - レコード編集時の境界判定の修正 - レコードの整列表示 - lsdb-mode-save に問い合わせを抑制するための引数を追加 * Mew と MU-CITE 用の設定関数を追加した。 * [XEmacs, Emacs21] モードラインの表示を派手にした。 * [XEmacs, Emacs21] X-Face の表示を高速化した。(要 netpbm) -- Daiki Ueno