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

Matzにっき


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)

もしかしたら勘違いしているのかもしれませんが...<br><br>>>>この変更では「外から呼び出されたくはないが、サブクラスで上書きしたい」要望が (もしあったとしたら)難しくなることが欠点である。そのような要望はあまりないような気がするが、言語はどのように使われるか分からないから、「ない」と断言するのも難しい。<<<<br><br>テンプレート・メソッド・パターンってまさにこれに該当しないのでしょうか? もちろん、protectedを使えば何の問題もないわけですが、privateをオーバーライドできるからには、そういう風に使う人は普通にいるような感じもします。

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

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

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

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

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

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

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

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

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

基底クラスを見ないのは使い勝手が悪いでしょうね。<br>printが使えないことになったら暴動が起きそうです。(笑<br><br>新しいvisibilityを導入する方法は私も考えたのですが、静的にコ<br>ンパイルしないRubyでは呼び出し方で区別するしか方法がなく、そ<br>うなると現在の関数的呼び出し方を流用するのが一番よさそうに思<br>えます。

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

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

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

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

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

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

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

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

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

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

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

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

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.