ruby-dev

In article <86y6uib0cd.knu@iDaemons.org>,
  "Akinori MUSHA" <knu@iDaemons.org> writes:

> 　ただ、 respond_to? における typo のリスクを仰るならなおさら、
> respond_to? での判定を助長するような変更はよくないと思います。

はい。typo の点で respond_to? が最善でないことには同意します。

respond_to? な理由には、duck typing との共通化と、定数やメソッ
ドを増やさないで済ますという点があります。

どちらも、ユーザが必要とする知識を減らすという意図です。

とくに、duck typing との共通化は、使えるかどうかを判定するに
は respond_to? を使う、というユーザの知識をできるだけ活かし
ていきたいという意味があります。

> 　端的に言えば Process.respond_to?(:fork) とシンボルで渡すから
> typo が見過ごされうるのであって、もし Process.forkable? とか
> Process.implement?(Process::FEATURE_FORK) のような手段が用意
> されるのであればそうした問題はないわけです。

たしかに typo の点ではそちらが有利だと思います。

ただ、これは今まで使っていなかった方法を導入するので、ユーザ
に新しい知識を要求します。

また、名前が増えるという点でも覚えることが増えます。

> 　NotImplementedError の捕捉でカバーできないケースとしては、
> たとえば fork する前に副作用のある前処理が必要なので、 fork
> する段になって NotImplementedError を出されても代替手段に切り
> 替えられない、といった状況が挙げられます。

はい。それが実行せずに判定したい、という要求の原因だと思いま
す。今回の rinda はそうではなかったようですが。

> 　さらなる悩みとしては、もし仮に Process.forkable? のような
> メソッドを用意し、上述のメソッドが冒頭で
>
>     Process.forkable? or raise NotImplementedError
>
> としたとしても、なおそのメソッド自体に NotImplementedError が
> 出ないかを事前判定する手段が必要になりそうだということです。

そうですね。最大としては、実装されていないことがあり得るメソッ
ドそれぞれについてそれを判定するメソッドや定数が必要になりま
す。

そうやってつくっていくと、名前はある程度規則的にはなるでしょ
うが、それでもゆらぎはでてくるでしょうし、決めること、覚える
こと、が多くなっていやなかんじがします。

たとえば、File.truncate に対して
truncateable にするか
truncatable にするかとか。

respond_to? の場合は、対象のメソッド自体の名前を使うので、そ
ういう悩みはありません。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

Thread

Prev Next

In This Thread

Prev Next