Hatena::Groupangelos

Angelos in Action RSSフィード

Fork me on GitHub
 | 

2009-09-23

roleを使ったときにわかりにくくなるケース

10:10 | roleを使ったときにわかりにくくなるケース - Angelos in Action を含むブックマーク はてなブックマーク - roleを使ったときにわかりにくくなるケース - Angelos in Action roleを使ったときにわかりにくくなるケース - Angelos in Action のブックマークコメント

今回のプラグインでroleを使う話とは関係ないのですが、role一般の話で、「roleを使ったときにわかりにくくなるケース」は、以下の二つになるのかなぁとtokuhiromさんらと話していて感じました。

  • roleをwithする側のクラスのコードを読んでいて、そのクラスにないメソッドがある場合に、どのroleに実装が書いてあるのかを調べるのが大変。roleが細かくわかれてると、特にこれが面倒になると。
    • 委譲にすれば、委譲先がコードとしてわかるのでおいやすくなると
  • aroundなどを使って拡張すると、どこで拡張されているのが拡張される側からみえないのでわかりにくい
    • これはhook pointが明示されていないからわからないという話で、hook pointを明示するべきという話に落ちるのかなぁと

# _buildやhandlesはMooseの仕様の問題でroleの話とは関係ないので上記では割愛してます。_build_*とかでbuilderを明示せずに書く書き方はよくないだろうなぁというのと、handlesも行数は減りますが、どこに委譲するのかがコードの流れの中からは消えるので、わかりにくくなるというのはわかります。仕様はimplicitよりexplicitであるべきで、Mooseの仕組みをわかってないとコードが読めないというのでは読みにくいだろうなぁというのは思うので、より明示的に書くべきなのだろうなぁと。

# roleの使用は適切に!という話で、roleを使う事自身が悪ではないです、というのを念のため補足しておきます

See also: コメント欄

http://angelos.g.hatena.ne.jp/dann/20090920/1253471666

# kazuhoさんの、「Interfaceは双方向の契約であるべき」というコメントは双方のケースを表すいい表現だなぁ。

  • 実装継承では継承する側が何をしなければいけないかがわかるべきだし、使う側では継承した実装がどこから継承した者かはすぐにわかるべき
  • hook pointもhook pointを設定する側とhookする側とで、双方向で契約として仕様がわかるようにすべき

という話なのかなぁと。実装継承の話は、今のRole(Trait)の仕組みでは難しいので委譲に頼るしかないかもしれないですが、hookについては別の方法があるだろうなぁと。

WebアプリでのI/O多重化の使い道

06:55 | WebアプリでのI/O多重化の使い道 - Angelos in Action を含むブックマーク はてなブックマーク - WebアプリでのI/O多重化の使い道 - Angelos in Action WebアプリでのI/O多重化の使い道 - Angelos in Action のブックマークコメント

クローラI/O比率が高いから明白なメリットがあるからわかるんですが、その他Webアプリでこれからどんな場面で使われていくのかは、いまいち想像しきれないなぁと思っていたので、どんなところに需要があるのかなぁと思って少し考えてみました。

1プロセス複数リクエストでのストーリー

リアルタイムWeb系ではc10k問題があるから、WebSocket関係で非同期サーバーの実装がいろいろでるのかもなぁ。そうすると、1プロセスで複数リクエストうけて、その中で継続+I/O多重化でスケーラビリティを保ちながらシンプルにかけるような実装が重要になるというストーリーはあるのかなぁと。

ただ、こうしたときに、perlライブラリではそもそもそんなの意識して書かれていないので、結局ライブラリの実装いちいち追わなくちゃいけなそうでだるそうだなぁという気はしたり。そこらはフルスクラッチ実装なのかなぁという気もしなくはない。若干perlを言語として使う事のメリットが失われる気もしつつ、これは時間が解決する問題なのかなぁとも思った。

前にmalaさんに、FastCGIのメリット・デメリットの話を書いたときに、1プロセスで複数リクエストうけるっていう使い方があるねというコメントをもらったのだけれど、ここに話の一部は繋がるの だろうなぁと。

1プロセス1リクエストでのストーリー

mod_perl + αで使う場面だと、1回のリクエストで多量のI/O多重化をしたいというケースなのかなぁと

とかなのかなぁと。

こっちのほうは、いかにもI/O多重化のメリットを活かしきれないので、あんまメリットはないかなぁという気はしますね。

その他のストーリー

もう少し過激なストーリーとしては、「非同期サーバーが当たり前の時代になって、全てのWebアプリI/O多重化と継続でかくことがWAFレベルでサポートされるようになって、利用者は気にしないレベルでかけるようになる」なんていうストーリーも少しはあるのかなぁと。そうなりだすと、上で書いた全てのストーリーは実現されるのが当たり前になっていると。

# 面白い分野だとは思うので、どんな使い道とストーリーがありえそうなのかをもう少し知りたいところですね。

 |