|
|
|
|
|
||
|
||
| 
YAPC後の飲み会でtokuhiromが話してたんだけど
DateTime->from_epoch(epoch => 1234567890);
PerlのDateTimeのfrom_epochメソッドは引数がハッシュなのね。from_epochなんだからepoch渡すに決まってんだろ！！！！という。こういう感性って、当たり前と言えば当たり前なんだけど、大事だと思う。ライブラリが他のライブラリからも利用されるようになると後方互換性が重要になり、変更を加えづらくなる。
Rubyの標準ライブラリとか作ってる人の話だけど参考になると思われる。
http://jp.rubyist.net/magazine/?RubyKaigi2006-0610-3
http://www.a-k-r.org/pub/rubykaigi2006-06-10.pdf
何でPOEよりもAnyEventを推しているかと言うと、文法がシンプルで覚えることが少ないからだ。簡単なサーバーを書くとか非同期クライアントを書くとか、そういう典型的な用途でAnyEventの方が楽で、だからPOEを必要とするケースと言うのは、ごく限られているだろうし、場合によっては全くなくなってしまうかもしれない。そもそもスレッドがまっとうに使えるのであれば、POEがこんなに成長することも無かっただろうしね。
AnyEventはイベント駆動の抽象化ライブラリで、POEはマルチタスキングフレームワーク(OSを模倣)なので、別にどちらが優れているとか一概に比較することは出来ない。単純には比較できない。POEは「POEの文法を好む」人が使えばよいと思っている。あれはライブラリではないフレームワークだ。POEという特定のフレームワーク向けに書かれたPOE::Component::*の再利用性は著しく低い。
文法がシンプルで覚えることが少ないと言うのは重要な価値だよ。書くことが短くて済むというのは、単に生産性の違いだけじゃなくて、メタプログラミングのしやすさにもつながる。PerlやRubyのような動的言語は動的に他のモジュールの挙動を変えることが出来る。気に入らないことがあったらちょっとだけ挙動を変える、みたいなことが良くある。だから同じ事を実現するにしてもシンプルで美しいコードってのはそれだけで価値をもたらすんだ。POEは長い歴史があって資産があるのは分かってるけど、その上で悪いデザインだと断定せざるを得ない。POEは「典型的な望みにAPIをチューンする」ということをやって来なかった。糖衣構文は作れるだろうが、今更それをやったところで内部構造が複雑であることに変わりは無く、すでに書かれたコンポーネントのソースは読むのが苦痛で、実現したいことに対して覚えなくちゃいけないことが多すぎるという状況に変わりはない。
Marc Lehmannはドキュメントの中で、似た機能を実現する他のモジュールに言及する。まあ大体これは他のモジュールをDISるためだったりするのだが、利用者は他の選択肢があることを知ることが出来る。AnyEventからPOEにはリンクが張られているが、残念ながらPOEからAnyEventにはリンクが張られていない。だからブログで書くけど、今からPOEで何かしようと思ってるなら、CoroやAnyEventを検討すべきです！！
