ruby-list

あおきです。

  In mail "[ruby-list:21164] Re: メソッドの入り口"
    Matsuo Hisanori <hisanori@sitc.toshiba.co.jp> wrote:

> 松尾です。

> > > 1) オブジェクトの型が想定しているものと違うかもしれない
> > 
> > > うけども、なんとなくスマートではないですよね。
> > 
> > must.rb(だったっけ?)ってのを使うと少しスマートに
> > 書けるそうですね。

ぼくが amstd/must なるものをでっちあげた帳本人です。

  str.must String

ってぐあいに使います。
が、しかし前に前田さんもおっしゃっていたように、Ruby において
型チェックはあまり推奨されません。理由は以下のようです。

* 多態性による使いかたの広がりがなくなる。

  たとえば、Array String IO にはどれも each と << が
  あるので

  def copy( src, dest )
    src.each {|i| dest << i }
  end

  の src dest のそれぞれについて三種類のどれを与えることもできます。
  しかしこれに型チェックをいれてしまうとその可能性を奪います。

* 型チェックは Ruby では本質的な意味をもたない。

  変数に型がある言語では型宣言が同時にインターフェイスの保証を
  することが多いです。しかし Ruby では undef alias instance_eval
  module_eval などを駆使すれば後からあらゆるクラスのインターフェイスと
  実装を完璧に破壊することができます。また、拡張モジュールを作れば
  クラスを「詐称」することも可能です。
  そのような環境においてクラスをチェックしてみても意味がありません。

* 結局、そのような場合(予想しない型がきた)の対処法はプログラマが
  プログラムを修正するしかない。

  これは、松尾さんがおっしゃっているとおりです。
  しかし、もちろんデバッグ時に「ここは String のはず」というように
  チェックをしておくのは意味があります。
  ぼくが must.rb を使ってるのもその点で意味があるからです。
  開発中のソースに .must をちりばめておいて、ちゃんと動くように
  なった時点で順次外していきます。


> > > 2) インスタンス変数へ代入するときはコピーをつくるべきか
> > 
> > 用途によります。この一言。

ぼくも賛成です。


> > > 3) メソッドの実行中に別スレッド中でオブジェクトが変化するかも
> > 
> > スレッドは疎いですが、これも用途次第かな…
> 
> スレッドセーフにしないといけないメソッドと、そうでないメソッドは分析過
> 程で分かってくる(嘘かも^^;)ので、心配しすぎる必要はないかも。再利用時
> にも使う前に分析するだろうし。

スレッドセーフでないなら「ここはスレッドセーフじゃないよ」
と書いておけばいいと思います。
また、データを変化させないでほしいならやっぱり
「変化させたら結果は保証できない」と書いておけばいいのだと思います。


ぼくもついついライブラリになんでもやらせようとしちゃうタイプなんですが、
別にライブラリ(とか)であらゆる状況の面倒を見る必要はなくて、
むしろ必要なのは、どのような責任を果たすのか、どのような限界があるのかを
明示することだと思います。

そういうのを言語として(不完全ながら)持ってるのが Eiffel で、
それはドキュメントと(人間の)意志疎通にまかせてもっと気軽に書こうぜ
っていうのが Ruby ではないでしょうか。
-------------------------------------------------------------------
あおきみねろう

Thread

Prev Next

In This Thread

Prev Next