mapleの現状とかフレームワークとか

mapleの問題点、というか気になる部分。

http://lists.sourceforge.jp/mailman/archives/maple-dev/2006-December/000242.html
これの詳細について反応をもらいました。
（MLで聞くべきだったのかな？ブログの方が大勢見てそうで、devは実際の開発者達が議論する場という雰囲気がする）

http://kunit.jp/maple/wiki/index.php?cmd=read&page=%B3%C8%C4%A5%2FFilter%2FWrapper
このフィルタは知らなかった。こっちの方がフィルタとして自然で使いやすそう。
私がmapleを使うとしたら、Convert2、Scarlet、FlexyView、Wrapperを入れて、そっちの機能をメインに使う。非常にhawkさん仕様になりそう。
後から拡張機能として出てきたというのもあって、これらの方がより洗練されている（と思う）。コアにマージした方がいいんじゃないだろうか。

http://blog.hawklab.jp/item-104.html
このエントリ、何だかしみじみ伝わってくる。

公開を前提としない個人的な改良では、「多くの人に対して公開するものだ」というレベルの緊張感を維持することはまずできない。新しいプロジェクトを立ち上げる場合でも、人が集められなければ同じことだ（そしてそうなる可能性は非常に高い）。かといって他のフレームワークに移るとしたら……どうだろうか。何を使うにせよ、「使いこなす」だけで満足することは到底できそうにない。そうなると結局同じことになりそうな気がする。堂々巡りだ。

そういう葛藤があって拡張機能として色々追加しているのか・・。
qmailみたいにパッチ地獄にならないような、mojaviに対するajaviにならないような、良い方法があればいいんだけども。

私の場合はフレームワークを公開サーバに置いているものの、（おそらく）自分以外に利用者は居ない。
だから思うままに変更している。
何故公開サーバにアップしているのかというと、そうすればコードを綺麗に書こうという気になるし、利用者が居なくてもソースを見る人は居るかもしれない。私は自分の使わないフレームワークのソースも時々見る。そういう人が他に居た場合を考えてかな。あとはマニュアルを簡単に書く/参照するためか。

id:kunitさんとしては、mapleは完成形なのかもしれない。自分の欲しい機能は全て実装してしまって、あとは補助的な機能があればいい的な。
mapleが有名になった理由としては
http://iteman.typepad.jp/blog/2004/12/post_6.html

Javaの国産DIコンテナSeasarの考えを持ち込み、PHPにおいて唯一DIコンテナを有するフレームワークとなっています。

これが大きいのかなぁ。
ただPHPにおいては $class->$method() や $class->newProperty = 'value' ということが簡単に行えるので、DIと呼ぶのがふさわしいかは疑問がある。Javaでの依存性を構築するコンテナという根本的な概念と、PHPで使われているDIコンテナの概念は違うんじゃないかな。
RailsにDIコンテナが無いように、PHPではPHPなりの解決法を考えたい。
そういうことを考えてると、なかなか既存のフレームワークに手を出すことが出来ないんだよな。

おとなり日記から
http://d.hatena.ne.jp/token/20061206

guessworkは『設定ファイルを書かなくて良い』ってのを長所に出してるけど、それって設定をずっと頭に入れておかないといけないって事につながるから精神的なストレスになるなぁ。

もう忘れかけてるけど、例えば

class SomeComponent
{
    public function someFunction(SomeClass $class){
        return $class->method();
    }
}

となっているとき、SomeClassをインジェクションする設定を書かなくていいっていうのは利点のみで不便なところは無いように思う。

guessworkって更新しないのかなと思って作者のブログを見てみると、最近はsymfonyを使ってるっぽい。ちょっと残念。

とりとめなくなってきたのでこの辺で投稿。。