フォーチュンサモナーズ
«前の日記(2006-03-31) 最新 次の日記(2006-04-08)» 編集

Don'tStopMusic

2003|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|12|
2006|01|02|03|04|05|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|08|

カテゴリ別 2003年 | 2004年 | 2005年 | 2006年 | 2007年 | 2008年

知り合いサイト: よんだもの / 暴想 / Linuxでやる夫 / 新宿Vipper / 僕だけが幸せになればいいのに。


2006-04-04

_ [Ruby]動的型言語の一番の問題点 このエントリーを含むブックマーク

babie さんが話題にしてたのでちょっと考えてみました。

自分の考える動的型言語の一番の問題点は、
 
    log_puts(out, msg)
 
ここのoutに何を入れられるのか、何を入れたらいいのか簡単に調べる方法がないという点です。

この「問題点」で困ったことがないです。ライブラリ/クラス/メソッドの使い方に迷うのは、オブジェクト同士の協調関係が把握できないためであって、メソッドのシグネチャのせいではないですね。例えば、net/http の使い方には良く迷いますが、Net::HTTP のメソッド呼び出しを書くのには困らないというか。

例えばシグネチャが log_puts(LogOutputStream out, String message) だったとして、LogOutputStream が知らないクラスだとしたら、out を log_puts に渡せる状態にするにはどうすればいいかは結局調べないといけませんし、そのコストは「何を入れられるのか、何を入れたらいいのか」という型を知るだけのコストよりも高いと思います。

更に言えば、log_puts(out, msg) を見て、out なら少なくとも IO (Ruby の標準クラス)が渡せるだろうと推測でき、またそれが裏切られることがあまりないならば、ますます型情報はメソッドを使うときのヒントとしては必要ありません。

この仮定を裏返して考えると、ユーザの推測を裏切らないためには、できるだけ推測し易いオブジェクトを受け入れるようにメソッドを書くことになります(実際にそうかどうか定量的に調べると面白いかもしれませんね)。

「できるだけ推測し易いオブジェクト」などといっても、必要だから IO ではなく LogOutputStream にしているんだと言われそうですね。ただ、動的型言語は基本データ型の標準クラス(Ruby だと String/Array/Hash など)が強力ですので、クラスの対象ドメインに特化したクラスをあまり作らない傾向があると思います。HTML の属性を表すのに HTML::Attribute クラスを定義せず、Hash でいいやとか。

本日のツッコミ(全1件) [ツッコミを入れる]
_ なおゆき (2006-04-05 11:17)

まったくもって、同意です。

[]

最近のコメント:

  1. tnoma (04-12)
  2. hwc (04-11)
  3. babie (04-09)

RSS
Creative Commons License
This work is licensed under a Creative Commons License
(note: text only. w/o web design, citations, (re)distributed softwares).