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-22)
[go: Go Back, main page]

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

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-22 [長年日記]

_ reddit.com日本語版

Paul Grahamからメールが来た。 Summer Foundersプログラムの卒業生が作った reddit.comの日本語版が出来たから、見てくれないかと。

どうも、ブックマークに近いのだが、「好き」「嫌い」を入力して訓練することでお薦めとか出してくれるようだ。こういうのはデータの数が重要なので、いろんな人が参加して、どんどんURLを登録してくれるといいと思う。

一番感動したのは登録が簡単なこと。AJAXを使っているせいもあるが、今までいろんなサイトで見た中で一番簡単だったんじゃないだろうか。

見たらshiroさんがさっそく登録していた。

_ [OSS] 「有名」になること(2)

たださんからトラックバックをもらった。

並みの自意識は持っているので、名刺を出すときにちょっとドキドキするわけなんだが、一度も気づかれたことはない。今日行ったところなんてブログ屋さんなのに、ビタイチ反応なしである。

いや、ブログ屋で、たださんに気がつかないっていうのはどうかしてると思うけど。

弾さんのフォローにもあったけど、とにもかくにも有名になることに意味なんてない。的確な分野で認知されれば十分なのだと思う。で、そういう意味では、たださんは十分有名だと思いますよ。

で、

まつもとさんが、NaClの「広告塔」としてどれくらい機能しているのか、興味があるな。対費用効果とか。たとえばNaClはけっこうCOBOL仕事もやっていると聞いたことがあるけど、そっち方面には広告効果はないよね、たぶん。一方で、広告塔が有効に機能する仕事もあるとは思うけど、じゃあそれが NaClにとってどれくらいメリットをもたらしているんだろう?

とのこと。実は、恐いので数値化はしないでいるのですが、首になってないところをみると、

  • それなりにペイしてる
  • 合理化の対象にならないくらいには、
    • 役立ってる
    • コストが気にならない

ということではないかと勝手に想像してます。

メリットは

  • 求人会社に広告を打つよりは安く、良い求人が集まる
  • 「まつもとがいるから」と仕事が来る(いや、ホントに)
  • 会社のポジションを説明しやすい(ただ、オープンソースを利用しているだけの会社じゃないんですよ)

などなどですが、これをどうとらえるか、ですよね。幸い、経営陣はポジティブに評価してくれているようです。

_ 風邪ひいた

昨日あたりから調子が悪い。一昨日の晩、マレーシアのスライド仕上げるのに夜更かししたからか。今日は早く休もう。未踏のスライド準備できてないんだけど...。

(関係者を不安にさせるようなことを言う)

_ [Ruby] private問題

で、風邪でぼーっとしてる頭でつらつらと考える。

モジュールを気軽にincludeした時に、そのモジュールが定義しているpublicなメソッドが取り込まれることは問題ない。その機能(メソッドの集合)が欲しいからincludeするわけだから。

しかし、内部的に使われるだけのprivateなメソッドが重複してしまうことは避けたい。重複を避けるために妙なprefixを付けるのもイヤだし、とはいえ、気軽にprivateが使えないのもイヤだ。

これを改善するにはRubyの挙動を以下の二点について変更すればよい。問題はその変更による影響がメリットを上回るか、だ。

まず、privateメソッドがpublicメソッドを(意図せず)上書きしてしまった場合に対応するために、 publicメソッドを探している時に、privateメソッドを見つけたら、そこで失敗せずにさらにスーパークラスを探索するようにする。

これはメソッド探索ルーチンに、今publicメソッドを探しているか、 privateメソッドを探しているかの情報を与えてやれば良い。変更は簡単だろう。この点は今までエラーになっていたものがエラーでなくなるだけなので変更による影響は少ない。

しかし、privateメソッドが、publicメソッドまたは別のprivateメソッドで上書きされてしまう問題は上記の変更では対応できない。

で、どうするかというと、「関数形式(レシーバを省略した形式)で呼び出したメソッドの探索は、メソッドが定義されているクラスを始点とする」という変更を加える。すると、関数的に呼び出されているメソッドの定義はサブクラスにより上書きされないことになるので、オーバーライドの心配が無くなる。

この変更では「外から呼び出されたくはないが、サブクラスで上書きしたい」要望が (もしあったとしたら)難しくなることが欠点である。そのような要望はあまりないような気がするが、言語はどのように使われるか分からないから、「ない」と断言するのも難しい。

「明示的にselfをレシーバとして指定した場合には、privateも呼び出せる(しかし、探索はオブジェクトのクラスからはじめる)」のような回避策が必要になるかもしれない。

あるいは、積極的な対応はせず「そういう使い方にはprotectedを使ってほしい」というのも手だろうな。

もうひとつの欠点は、メソッドの呼び出しセマンティクスが複雑になることだ。今の「メソッドを呼び出す、しかしpublic/protected/privateという可視性がある」というモデルも十分複雑なのに、それ以上複雑にする意味があるのか。

個人的にはあるような気がしているのだが。

本日のツッコミ(全12件) [ツッコミを入れる]
_ まつもと (2006-02-22 19:45)

また、にっきが壊れていたようです。

_ ベン (2006-02-22 23:05)

もしかしたら勘違いしているのかもしれませんが...

>>>この変更では「外から呼び出されたくはないが、サブクラスで上書きしたい」要望が (もしあったとしたら)難しくなることが欠点である。そのような要望はあまりないような気がするが、言語はどのように使われるか分からないから、「ない」と断言するのも難しい。<<<

テンプレート・メソッド・パターンってまさにこれに該当しないのでしょうか? もちろん、protectedを使えば何の問題もないわけですが、privateをオーバーライドできるからには、そういう風に使う人は普通にいるような感じもします。

_ まつもと (2006-02-22 23:22)

該当します。だからそういう使い方をしている人もいるでしょう。
問題は今後そういうことができなくなる(違うやり方をせざるをえなくなる)点がどれだけ大きな影響があるか、メリットと比べてデメリットがどうか、という点です。トレードオフですね。

_ 通りすがり (2006-02-23 12:20)

privateには手を加えないで、新たにsuperprivateを導入するとか…

_ Matz Jr. (2006-02-24 09:35)

娘です。
読みました。
なんかよくわかんないけどお父さんも
ちゃんと会社に貢献してるんだね(たぶん)
風邪は、ちゃんと寝てください。

_ Gimite (2006-02-24 21:46)

いっそのこと基底/派生クラスのprivateメソッドは一切見にいかない(オーバライドしたければprotected)というのはどうでしょう。privateの意味を変えるよりは別の名前にする(通りすがりさん説)のが無難かもしれませんが。別名にするならfinalとか…?

_ まつもと (2006-02-25 09:35)

基底クラスを見ないのは使い勝手が悪いでしょうね。
printが使えないことになったら暴動が起きそうです。(笑

新しいvisibilityを導入する方法は私も考えたのですが、静的にコ
ンパイルしないRubyでは呼び出し方で区別するしか方法がなく、そ
うなると現在の関数的呼び出し方を流用するのが一番よさそうに思
えます。

_ Gimite (2006-02-26 13:52)

あ、そうかprintは基底クラスのメソッドなんですね…(汗)。

_ 初心者 (2006-03-02 02:06)

新しいvisibility案で、呼び出し方じゃなくて、呼び出し場所で区別というのは出来ないのですか?module内外。
まあ、そんな簡単なことだったらお悩みじゃないんでしょうけど。

_ まつもと (2006-03-02 07:57)

呼び出し場所、ですか?
あまりイメージできないんですが、「module内外」というのはどう
いう場所の呼び出しがlocalで、どういう場所の呼び出しが通常の
ものになるんでしょうか。

_ 初心者 (2006-03-05 01:05)

modele内でのsuperprivate(仮)メソッドは、module内からは呼べるが、includeする側のclassのメソッドを上書きしないことにするということですけど。

_ まつもと (2006-03-05 23:55)

モジュールに限定したlocalメソッドって感じですかね。
localにくらべてどう嬉しいんでしょうかね。

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

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

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