APEL 問題、再燃?

Mikio Nakajima minakaji @ osaka.email.ne.jp
1999年 11月 7日 (日) 08:48:47 JST


  おはようございます、中島@あさひねっとです。


# 本件についてリプライ下さるなら、apel-ja は anyone can post になりま
# したので、Cc して下さいね。


At Thu, 04 Nov 1999 20:59:49 +0900,
Makoto MATSUSHITA <matusita @ ics.es.osaka-u.ac.jp> wrote:
 
> 「いま使いたいと思っている application が要求している APEL (が持っている
> 機能)」を「現在すでに install されている APEL」が提供してくれているのか
> どうかを判定することはとっても重要なんじゃないかと思っています.
> # どの version を入れたのかを覚えている人ばかりが使うのであれば構わない
> # ことではありますが,そういう前提を置くのは辛い気がします.

  SKK 10.x を書いているときのぼく (XEmacs 21.2.19 と Emacs 20.4 を使っ
ています) の立場は、最新の Emacsen で実装されている関数、マクロをでき
るだけ使う、というものです。これは、最新の Emacsen で実行すれば多分最
も速く効率の良いプログラミングだと思うからです。

で、はたと古い Emacsen にはその関数、マクロがないこと、また、APEL にそ
の関数、マクロが実装されていないことに気付いたときは、tm-ja (既に
apel-ja になりましたが) にこれを実装しませんか、と提案しつつ、SKK 側は
それが実装されるまでの間、どちらの Emacsen でも動くように補強を入れま
す。APEL にそれが実装されれば、SKK 側の補強を取り去って、required APEL
の version を上げます。

# ちなみに APEL で提供する関数、マクロがこういう場当たり的に実装され
# ている、という問題については、tm-ja で既に議論されていて、もう少し
# 体系的に処理できるよう何とかしようと思っています。
 

At Wed, 03 Nov 1999 23:55:24 +0900,
Makoto MATSUSHITA <matusita @ ics.es.osaka-u.ac.jp> wrote:
 
> 以前からの疑問の 1 つなのですが,特定の version 以降のものを使って欲しい,
> というような代物でありながら,program 側で version を特定できない(つまり,
> SKK が現在使える APEL の version を知ることができない),というのはとって
> も不便だと思うのですが,どうして APEL は自分自身の version がいくつなの
> かを教えてくれないのでしょう?

以上のようなプロセスを知っていただくと、SKK 10.x が APEL の比較的最近
の特定のバージョンを要求しているのは、SKK 10.x 側の都合であって、APEL
のせいではないことが明かでしょう (APEL の required version を上げずに
おこう、と思えば前述の SKK の補強を残しておけば良いわけですから)。

実際、Wanderlust のように APEL がある程度古くとも自前で対応できるよう
にしている applicaiton もあります。SKK 10.x は APEL と共に成長すること
を前提とした開発版なので、少しでも余分なコードは減らしたいですから、そ
ういう慎重な立場は取りませんが...。


  だから SKK のプログラムの中では、

At Thu, 04 Nov 1999 20:59:49 +0900,
Makoto MATSUSHITA <matusita @ ics.es.osaka-u.ac.jp> wrote:

> 「使いたい function があって,それは最新版の APEL ではあるが,すこし古い 
> APEL にはない」という状況を考えると(これは十分ありえそうな場合だと思いま
> すが),おそらくそういう function を使う側としては
> 
> 	- Emacs 自体にそもそもその function があるならそれを使う
> 	- なければ APEL で該当する奴を require してそれを使う

という二段階の判定はしておらず、ただ単に最新の Emacsen の関数、マクロ
が define されていることを前提にしているだけです。APEL は load 時に
Emacsen がその関数、マクロを持っていなかったらそれを提供し、持っていれ
ば何もしません。

すなわち、SKK 側は動く段になって、APEL の version がいくつかなー、とい
うお伺いは立てることがありません。


> 「APEL が持っていると思って require したのに,実はそ
> の function はなかった」という場合,普通「function ないぜ」といって実行
> が停止するでしょう.APEL の version が判定できるならば「古いから新しい奴
> を install してくれ」と適切に application が判断できるようになる気がして
> います.
 
そういうコードを SKK 側に入れることはできますが、そのまま開発を続けて
いると、あちこちで APEL の version を尋ねる羽目になり、効率的とは言え
ません。APEL の verison が define されても APEL とのそういう対話はしな
いつもりです。


>ただ,個人的には APEL はどう考えても Emacs と一緒に配布されない限り絶対
> に幸せになれないと確信していますし,そうなって欲しいと思っています.

  こう確信される理由が分りません。


> 私は APEL がやろうとしていることが嫌いだといったことは一度もありません
> (現状のままの実装およびその形態は嫌いだといったことはありますが).どちら
> かというともっと APEL として幸せになれる方法はないのだろうか,現状はとっ
> ても不幸だと思うのにどうしてどうにもならないんだろうと思っています.
> (中略)
> ただ,
> そのために自分ができることが(残念ながら)多分ほとんどありません‥‥
> (中略)
> 少なくとも code は書けない

  具体的な不都合を正確に報告すること、改善案があれば具体的なコードを書
かずとも、apel-ja で提案してみることで、 APEL に貢献できると思います。
apel-ja は anyone can post になりましたので、日常講読される必要はあり
ませんし。

APEL の開発には関知しない立場を取りながら、不正確な信用不安説をとなえ
ることは (過去に実際に APEL の不都合があったにせよ)、無用の心配を他の
人に波及させる悪影響はあっても APEL (あるいはそれが目標とするところ)
自体の前進は全くないと思います。

どんなに小さなことでもご協力をお願いできたら非常に助かります。

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




More information about the APEL-ja mailing list