«前の日記(2006年02月17日) 最新 次の日記(2006年02月19日)» 編集

Matzにっき


2006年02月18日 [長年日記]

_ [教会] 掃除

教会の掃除当番。片付けて、掃除機かけて、ゴミ捨てて、イスを並べる。きれいになった。家族総出でやればそんなに時間はかからない。

世間的には大家族らしいので。

_ [Ruby] 多重継承言語としてのRuby

Rubyはフル機能の多重継承を持たずMix-inしかないので、世間的には単純継承言語(+α)と認知されていると思う。

が、世間での認知はともかく、Mix-inが多重継承の一形態である以上、実質的に多重継承的な使い方が出来ることは厳然たる事実だ。

多重継承のある言語としてRubyを見ると

  • インスタンス変数が全クラス階層で共有される
  • privateメソッドとpublicメソッドの名前空間が同じ

という二点はかなり痛い。

前者は継承に参加する全クラス(モジュール)間で名称に衝突があってはいけないことを意味する。単純継承言語ではこの条件はあまり厳しくない。スーパークラスへのラインは一本しかないので調整が難しくないからだ(にも関らずSmalltalkではインスタンス変数はクラスごとに独立だったはず)。しかし、多重継承言語では継承してくるクラス(群)が独立で調整が効かない場合があるので、この制限は厳しい。この点ではクラス名を明示する必要があるC++や名称変更機能があるEiffelの方がはるかに優れている。

っていうか、クラスをモジュールとして考える(OOSC的)立場からは C++ってかなり良い言語なんじゃないかなあ。MeyerはC++大嫌いみたいだけど。

意外なことにCLOSでは(少なくとも標準のMOPでは)スロットの名称重複は継承優先順位の高いものだけが優先になり、解消の余地がない。

後者は局所的なサブルーチンとして使おうと思ったprivateメソッドがよそのクラスのpublicメソッドと名称が重複していた場合、現状では上手な解決策がないことが問題だ。 Rubyには原始的なaliasとundefがあるが、この問題はこれらでは解決できない。

で、だ。

どちらの問題にも解決のアイディアはあるのだが、効率と互換性の両方に懸念があるのだな。

詳細は後日。

_ [Ruby] Rails' Ridiculous Restrictions, a Rant

Joel on Softwareサイトの掲示板への投稿。 Railsの気に入らない点について。

書いた人は「a Hack」さんで、あちこちで誤解されているようだがJoelではない。

気に入らない点は以下の通り。

  1. RDBのメタデータ(外部キーなど)を見ないので、テーブル間の関連は別の場所(Rubyコード)で記述する必要がある。
  2. 修正するたびにリスタートしなければならない
  3. マニュアルがひどい
  4. varchar(40)に80文字データを入れても知らんぷり
  5. 知られざるルールが多い
  6. 設定コードがあちこちに分散している

ただし、「気に入らない」と文句を言いながらも、その実は「I only say all this because Rails is the first framework worth criticizing.」であるとも述べている。

これに対して、DHH本人が反応している。こまめだね、彼も。

  1. 外部キーは関連を表現するのに十分でない。不完全な情報に頼るよりは明示的に記述したほうがよい
  2. 勘違いだと思う。development modeを知らない
  3. 同意する。(http://www.railsmanual.orgというサイトがあるとの情報あり)
  4. バリデーションも明示的に行われるべき
  5. 同意する。まとめるのに協力がほしい
  6. 設定コードは一ヶ所にまとめるべき。誰かが間違っていたら、直せるよう指摘してあげてほしい

«前の日記(2006年02月17日) 最新 次の日記(2006年02月19日)» 編集