Re: backquotes
[email protected] (守岡 知彦 / MORIOKA Tomohiko) 06 Sep 2007 00:24:53 +0900
| Newsgroups | gmane.mail.emacs.mime.japanese |
|---|---|
| Message-ID | <[email protected]> |
>>>>> In [emacs-mime-ja : No.02187] >>>>> Katsumi Yamaoka <[email protected]> wrote: > >> ある版の Emacs が使わないコードを確実に load しないようにすれば > >> 良いのでしょうけれど、それは大変そうです。実際、今では要らないも > >> のがたくさんありますね。それらが一斉に火を吹いた感じです。 > > eval されることなく、error が起こらなければそれで十分だと思うので > > すが。 > 国内外を問わずそれが主流の考え方のようですね。一方ぼくを含めた少 > 数派は、明らかに害の無いコードに対して発せられる警告を気にします。 > これは単に見栄えだけの問題ではなくて、コンパイル時にわんさか警告 > が出るプログラムの場合、真にバグに対して出された警告をも見なくな > る害があると思っています。 grep を使うとか、log を filtering するのはいかがでしょうか? > > ;; 個人的には、機械的書き換えに対して、上記のような心配を持ってし > > ;; まうので。あくまで、個人的印象なので、人それぞれだとは思います > > ;; が。 > 機械的書き換えには違いありませんが、変更の大半はいろんな角度から > 検証済みです。「機械的」の意味は、例えば macroexpand の新旧の結 > 果を比較することです。 実装前(書き換え前)に検証することは当然のことですが、それとは別に、書 き換えた code 自体もチェックした方が良いと思います。トリビアルな変更で あっても、思わぬミス(あるいは、事故)はありうる訳ですから、code を書 き換えたら cvs commit する前に必ず diff を見ることは必要ですし、動作を チェックすることもなるべくやった方が良いと思います。 ;; 本当はテストスイートがあれば良いんですけども。 ;; ちなみに、CHISE の文字データベースを書き換える時は、どんなわずかな ;; 修正であっても、コンパイラなんかと同様な不動点チェックを通過するま ;; で cvs commit しないという方針を取ってたりします。その上で、差分も ;; チェックします。 > > とりあえず、FLIM の変更に関しては、まず、emacs-mime-{ja|en} で議論 > > してからやるのが良いんじゃないでしょうか? > > ;; 枝の持ち主以外がいきなり commit するのは望ましくない気がします。 > 変更に際しては提案し、評決を経て実施するというルールを忘れたわけ > ではないのですが、それはすでに崩壊していると思います。いったい、 > 有益な議論が行なわれたことが何回あるでしょうか? > そもそも何か変更を行なう人は、その人の尺度で十分に煮詰めたものであろ > うし、それを他者が詳細に検証するのを待って実施するのでは非常に効率が > 悪いでしょう。ぼくもそうですが、そのとき興味が無ければ「それでいいん > じゃない」すら言わないし、唐突に出てきた提案をすぐにみんなが検証して > くれることを期待するのは無理があります。特に、深刻な問題提起を繰り返 > すユーザーに対してすら誰も反応しない現状では、そんな手順に意味がある > とは思えません。cf. [emacs-mime-ja : No.02148] emacs-mime-{ja|en} に投稿するのは、第一義的には『有益な議論』をするた めではなくて、記録を残すためです。これは、現在の私のように、すぐに反応 できない人にとって、極めて重要なことです。これをやらないと 「cf. [emacs-mime-ja : No.02148]」というように、指し示すこともできませ ん。 反論がなければ実施すれば良い訳ですし、time out の期間は自分で決めるこ ともできます。cvs commit しなくても開発はできます。さらにいえば、自由 に自分の枝を作ることだってできます。flim-1_14 枝に commit する前に一言 その意図を書くというのはそんなに非効率なものでしょうか?重要だったり 深刻だったりするなら、なおのこと記録に残すべきじゃないでしょうか? ;; また、『その人の尺度で十分に煮詰めたものであろう』から良いとするの ;; は、ソフトウェア工学的にはちょっとまずい主張ではないかと思います。 ;; それから、信頼性よりも開発を優先するフェーズ(例えば、開発用の枝) ;; では、効率を重視した方が良いと思いますが、枯れたソフトウェアでは信 ;; 頼性を重視した方が良いと思います。そして、それは工学的には、プロセ ;; スによって保証するものではないかと思います。 少なくとも、flim-1_14 枝および将来の(開発枝 (status = alpha) ではない) 『公式枝』に関しては、従来の方針通り、(メインテナー以外の人が)事前の 宣言なしに cvs commit するのは止めて欲しいです。 ;; もっとも、私以外の誰かがメインテナーを引き受けて、方針を変えるなら ;; ば、その限りではないですが。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ / ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <[email protected]> ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━