Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Matzにっき(2006-02-18)
[go: Go Back, main page]

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

Matzにっき

<< 2006/02/ 1 1. 『よくわかる現代魔法
2. ActiveState To Spin Out
2 1. Rast高速化パッチ
2. レノボ、Core Duoを搭載したThinkPad X60 / T60を発表
3 1. ruby_class削減
2. Rastが遅いわけ
3. 英会話
4. 雪
5. コンピュータは難しすぎて使えない
4 1. 参観日
2. 『コンピュータ技術者になるには』
3. Ruby温泉ミーティング2006春
5 1. 断食安息日
6 1. 日経Linuxとオープンソースマガジン 2006年4月号
2. るびま 13号
7 1. 日経Linux
2. 日本国民全員にプログラマになってほしい
8 1. 妻の誕生日
2. 日本政府はさっさとオープンソース振興から手を引いてしまえ
3. 良書
9 1. デベロッパーズサミット
10 1. デブサミ2日目
2. 「サミット」
11 1. 実家へ
2. 『i』
12 1. 松江
2. バリアフリー
13 1. Why Ruby?
2. WebプログラマはRailsに乗るべきか?
3. Language Design Is Not Just Solving Puzzles
4. 第7回アジアOSSシンポジウム
14 1. バレンタインデー
2. 機械は人狼を見つけられるかな
3. C#への期待。アンダースからの返答
15 1. オープンソースマガジン・ゲラ
2. 小人さん
3. 「仕事でオープンソース・ソフトを開発したければ有名人になれ」,Seasar2開発者のひが氏
16 1. 日経Linux・ゲラ
2. Otaku, Cedric's weblog: Python going extinct?
3. 競争に打ち勝つための最新武器--オープンソース
17 1. ご当地バカ百景
2. OSSにとってどのような支援策が必要か?
3. 定数探索ルール変更
18 1. 掃除
2. 多重継承言語としてのRuby
3. Rails' Ridiculous Restrictions, a Rant
19 1. 娘のお話
2. バプテスマ会
20 1. お客さま
2. るびマっ 13号
21 1. 「Matzにっき」が壊れた
2. 「有名」になること
3. テレビ出演
22 1. reddit.com日本語版
2. 「有名」になること(2)
3. 風邪ひいた
4. private問題
23 1. 体調不良・スライド
2. 父親の誕生日
24 1. 平成17年度上期未踏ソフトウェア創造事業 千葉PM 成果報告会
2. 『Joel on Software
25 1. 次女誕生日・買い物
26 1. 定例集会・監査
27 1. private問題、その後
2. 復刊ドットコム
28 1. Joelが腹立たしいわけ
2. Ruby2.0への一歩
>>
迷惑メール対策なら Dr.WEB
『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です!


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. 設定コードは一ヶ所にまとめるべき。誰かが間違っていたら、直せるよう指摘してあげてほしい
本日のツッコミ(全9件) [ツッコミを入れる]
_ とみた (2006-02-21 07:53)

「とう差異と」→「というサイト」?

_ まつもと (2006-02-21 08:29)

ああっ、直したと思ってたのに。ありがとうございました。

_ むらやま (2006-02-21 08:58)

「名勝」 -> 「名称」?

_ まつもと (2006-02-21 09:05)

えーん。直します。ありがとうございました。

_ shiro (2006-02-21 10:08)

CLOS的には、「スロットの名前の衝突はパッケージで回避してね」ということなのでしょう。

_ まつもと (2006-02-21 13:56)

でしょうね、たぶん。> パッケージで回避。
CLOS流に慣れてない私には使いこなせません。

_ (2006-02-21 16:25)

本文と関係無くて申し訳ないのですが、
最近rssにだけ載っている記事をよく見かけます。(クリックすると「日記はありません」)

_ まつもと (2006-02-21 16:44)

「あ」さん、報告ありがとうございます。

きちんと調べてみたいので、今度「日記はありません」と言われた時にそのURLを教えていただけませんか? ここのコメントでも私にメールするのでも構いません。

_ アジャ (2006-02-22 13:17)

どれもRailsの本質ではないですよねー(^^;
故意的な野次に見受けられます。
相手にしない勇気も必要か。

お名前:
E-mail:
コメント:

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

RSS feed meter for http://www.rubyist.net/~matz/ Creative Commons License This work is licensed under a Creative Commons License.