APEL 問題、再燃？

[Mikio Nakajima]

  こんばんは、中島＠あさひねっとです。

At Wed, 03 Nov 1999 18:03:41 +0900,
Makoto MATSUSHITA wrote:
 
> が，現状の SKK 10 は APEL が持つ全ての実装を SKK が使っているわけではな
> い，ですよね．とすると，
> (中略)
> もしそうなのであれば，APEL の必要な部分だけを SKK にひっぱってきてそれを
> 読めばそれで十分だったりはしないのでしょうか．変数名や関数名を適宜機械的
> に置換することによって，十分 SKK *だけ*のための APEL (という表現はへんで
> すが)を作れそうな気が，なんとなくするのですが‥‥

  APEL から必要な部分だけを APEL から千切ってきて、SKK にくっつける、
という意味でおっしゃっているのであれば、それをどなたかがやって下さるの
であれば否定はしません。

しかしそういう二度手間なことをやるのはメンテナンス性を下げるので、ぼく
はその non APEL required バージョンを保守することを放棄します。ぼくは
その時間があれば APEL 自体の精度を上げる方に貢献したいです。

APEL から必要なファイルだけを取ってきて SKK のディストリビューションに
加える、というのは検討の余地があるかもしれません。しかし、システムにイ
ンストールされている APEL が同封の APEL より新しいかどうか、インスール
時に判断するようにインストーラーを改善する必要があり、一方で APEL の
version 情報をポータブルに判断する方法が提供されていないので、少し面倒
な気がします。


> 私が SKK が APEL を使うことに対して妙な心配をしているのは以下の 2 つです．
> 
> 1つめ)
> 	仮に SKK 10.x が晴れて release されたとします．その n ヶ月後，
> 	SKK の version をあげないまま，他の(SKK とは無関係の)
> 	application によって要求されたために APEL を最新版に更新したとし
> 	ます．
> 
> 	この時(リリースされた) SKK 10.x が問題なく動いてくれるのならば，
> 	SKK が APEL を使うのは構わないと思います．でも，それを SKK 自身
> 	では多分保証できないような気がしてなりません(APEL 側の都合もある
> 	はずですから)．
> 
> 2つめ)
> 	私の記憶が間違っていなければ，現在の APEL は 9.x だと思います．
> 	SKK 11.yのリリース版が出る前に APEL が 10.y に進化するかもしれま
> 	せん(しないかもしれませんが)．そして，APEL 10.y でしか動かない別
> 	の(SKK とは無関係の) application を使うために APEL 10.y を 
> 	install したとします．
> 
> 	この時「(リリースされた) SKK 10.x が APEL 10.y と一緒でも問題な
> 	く動く」か「APEL 9.x と APEL 10.y はどちらも install して(互いに
> 	影響を与えることなく)利用できる」のならば，SKK が APEL を使うの
> 	は構わないと思います．でも，それを SKK 自身では多分保証できない
> 	ような気がしてなりません(APEL 側の都合もあるはずですから)．
  
  API の異なる、複数の、かつモジュール名 (poe とか pces とか) が同一な
APEL をインストールするのはまずいと思います。モジュール名を全く違う名
称にして、SKK からそのいずれかのモジュール名を特定して require するこ
とで、APEL のバージョンを特定することができれば問題は発生しないはずで
すが...。

  しかし、APEL の API (などと言うものがあるのかどうか知りませんが) が
変って上位互換性がなくなるのは APEL の目的に反するので、あり得ないと信
じています。


> # APEL というのは Emacsen の進化にあわせて自分自身も進化する必要があるは
> # ずですから，私は APEL が本質的に backward compatibility を保ちながら成
> # 長できるとは思えない，という印象を持っています．

以前にも松下さんは同趣旨の発言をされていたと思いますが、その際の守岡さ
んのリプライを引用します。思い出して下さい。


At 12 Nov 1998 22:27:14 +0900,
守岡 知彦 <morioka ＠ jaist.ac.jp> wrote:
> 
> >>>>> [tm(ja) / tm ML (日本語版) : No.3789] にて
> >>>>> “西田”= NISHIDA Keisuke <knishida ＠ nn.iij4u.or.jp> さま曰く:
> 
> 西田> > From: Makoto MATSUSHITA <matusita ＠ ics.es.osaka-u.ac.jp>
> 西田> > Subject: Re: SKK 10.47.3
> 西田> > Date: Mon, 09 Nov 1998 10:13:18 +0900
> 西田> > 
> 西田> > > APEL 8.x で動く application と APEL 9.x で動く application が
> 西田> > > 世の中にあって(昔のことなのでそれが何だったか忘れてしまいまし
> 西田> > > た)，でも APEL は両 version ぶちこめないので(まあそりゃそうな
> 西田> > > んですけれども)ちょっと困った記憶があります．
> 西田> > > 
> 西田> > > # 共通な infrastructure を作るためのものなのに，それら同士で共
> 西田> > > # 存できない というのは，直感的にはかなり納得できないのでした 
> 西田> > > # :-)
> 
> APEL は tm 7.106 の emu に対して字面上の上位互換性を持つことが意図されて
> います。
> 
> また、APEL 9 は APEL 8 に対する字面上の上位互換性を持っているはずです。
> 
> 『上位互換性を持っている』とはっきりと書けないのは、関数を macro に変え
> たり、macro の実装が変わったりすると、emu を使った module を再 compile 
> する必要があり得るからです。最近は問題を避けるために関数は関数で
> emulate する原則を守るように努力しています（でも、へまはあり得ます
> (^_^;）。
> 
> いずれにせよ、仮に問題が起こっても recompile すれば直るはずです。
> 
> とにかく、意図的に問題を起こしている訳ではないので、問題があれば
> bug-report を送って頂ければ対処できるのではないでしょうか？

  XEmacs/FSF Emacs が異なる道を歩む以上、APEL は成長し続けないと意味が
ありません。様々なアプリケーションが APEL を利用する以上、成長しても上
位互換性がないと APEL は破綻することとなると思います。松下さんのおっしゃっ
ている backward compatibility はこの「上位互換性」とは異なる意味でおっ
しゃっているのですか？


> APEL が SKK *だけ*のためにあるのならば大丈夫だと思いますが，それは決して
> 違いますよね ^_^;

  そういうふうにしたいのであれば、SKK community で独自に開発する必要が
あります。しかしながらぼくは、SKK community だけで現状の APEL が提供す
る emulation 機能が提供できるようになったとは思いません。

-- 
中島幹夫 <minakaji ＠ osaka.email.ne.jp>
　　　　 <minakaji ＠ pdx.ne.jp> (急ぎのときはこちらへ)
http://www.asahi-net.or.jp/~gy2m-nkjm/