で、そのSingletonとやらをどう有効に使えるのかね？ｗ
PHPだぞ、これ。Javaじゃない。
ふっつーにグローバル変数で何の問題も起きない。起こしたら本格的に痴呆だ。

まあそうね
PHPSDLとかイロモノ出て来てるの見ると、色々考えちまうがw

>>801
ライブラリやフレームワークでの記述の統一が無視できないと思う。

あんたの書いたライブラリで$GLOBALS['hogehoge']['pagepage']['instance']とか、
誰が使うかｗ
Hogehoge::getInstance() の方が憶えやすいし、見通しがいいに決まってるじゃないか。
ただの$_SESSIONアクセサ+アルファで、別にそれほど目立った特色のないSession
クラスや同様のCookieクラスが一部で存在する意味もそれだろ。

こういった要素を軽視する人間と一緒に作業できそうな気はあまりしない

>>803
>>801はフレームワーク不要とか言ってる人と同一人物じゃないかな？
趣味プログラマだと思うから、状況が違うんでしょう。
おそらくJavaで仕事したこともないからこその発言に見えるね。
なので議論は（フレームワーク不要論と同様に）平行線になるね。

まともなJava屋から「グローバル変数で何の問題も起きない」なんて発言が出るわけないもんな。

>>801
>>803とは違うことだけど、安全性の問題かな

このファイルをincludeすると、$なんとか っていうグローバル変数が
定義されますっていうのはちょっと・・・。
グローバル変数への格納・利用が、同一人物が同時期に書いたソース
のみで起こるんならまだいいんだけどね。

Xoopsも結構良くできてたけど、プラグインを作るときにこの辺が物凄く
引っかかった。クラスベースでも、覚えたりソース読んだりするのは同じ
なんだけど、少なくとも汚染されていない保証っていうのかな、そういう
ものが大事だと俺は感じた。

あまりむやみにグローバル変数を作るのはよくないけれど、限定された使い方ならいいと思う。
どうせシングルトンの対象になるのって、DBコネクションとか限られてるんだから。

Singletonだと継承した時、Singleton部分を再実装しないといけない
どうせSingletonの意味は薄いんだから、クラスは普通に書いて
Factoryで管理した方がいいかもね

>>808
意味がわからない。kwsk plz

>>808
agaviはContextクラスがAgaviModelの派生クラスのファクトリーになってて、
IAgaviSingleModelインターフェイスを実装している場合はSingletonになるようにしてる。

>>808
想定しているのはこういうのじゃなくて？
＃ これなら継承しても特に問題なさそうなんだけど・・・

class A
{
protected static $obj;
public static function singleton()
{
if(!isset(self::$obj)){
self::$obj = new stdClass();
}
return self::$obj;
}
}
class B extends A{}

var_dump(B::singleton());

ああ。なんとなくここまで流れで見えてきたポイントがある。

>>811 での Bクラスの singleton() では、例えば Aクラスを継承した
Cクラス・Dクラス・・・でも、「同じ」インスタンスが返ってくるなｗ

class B extends A{}
+ class C extends A{}

var_dump(B::singleton());
+ var_dump(C:::singleton());

んで、ぐーーーーっと戻るが、>>788 での記述でAクラスが書かれて
いたとすると、結果が変わる。
BクラスとCクラスでは、戻ってくるインスタンスが違う。
結局、こういうことなのかな？

詳しい人、解説頼む

時代はSingletonなのか？　

>>809
オブジェクトを管理しやすいんじゃないか？

シングルトンは初期化のタイミング気にしなくて良いのも大きいやん

>>813
シングルトンは昔からあるデザインパターンの一つだよ。

DIコンテナがあればシングルトンパターンなんて使わねーから。
そんなことより、JavaもPerlもRubyもMVCフレームワークって
ほぼ１択なのにPHPは乱立してんの？
決定版が出てこない時点で終わってるな。

>>816
ある意味、PHPの敷居の低さかな。もともとWEBフレームワークみたいなものだから、
基本機能（CookieだとかHTTP周りとか、出力とかサーバへのデプロイとかもろもろ）を
スキップしていきなり構築出来るし、書いてみれば結構できちゃった、みたいな感じじゃね？

>>816
DIコンテナ何使ってる？

・DIコンテナって何？その用途・利点は？
・DIコンテナとsingletonの関連は？
・DIコンテナを使ったPHPフレームワークってある？その得意とするケースは？

初心者が、ここでこれくらい聞いてもいい？

だーめっ☆

>>816
> ほぼ１択なのにPHPは乱立してんの？

PHPがオープンだからじゃないかな？

Javaも最近オープンになってきたから
フレームワーク増えてきているよね。

>>819
ググれカス

話についていけない！
Javaを勉強しないといけませんか？＾＾

>>823
やさしいJAVA

>>824
いやいやｗ それデザパタとかないしｗ

まずは、DIコンテナが有効なのかどうか、その辺の話が出来ないのか？
ググっても古い情報しかないのは、もう廃れたのか、常識的に使われている
からなのか、どうなんだ

基本的に、手法がXML等の外部設定ファイルだろ？PHPに馴染むとは思えん。
俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。

PHPになじむかどうか以前に、

XMLなどの外部設定ファイルで設定するのって
大変だよ。

>>816
Javaのフレームワークがほぼ一択だと思ってるなら、無知すぎ。
Rubyは開発者が少なすぎの過疎言語だったから。
Perlも廃れた言語だから。
Pythonも多い。

PHPも、乱立っても紹介が多いだけで、実際使われてるフレームワークは
限られてる

>>826
特にXMLは大変だな。あの可読性の低さは尋常じゃない
専用エディタ使え？ああそうですね

PHPって、まともなクラスライブラリがないから、それぞれ独自でフレームワークを実装し出すんだよ。

DIコンテナ=XMLの設定ファイル使う、じゃないでしょ。
yamlの奴とかもあるよ

>>829
zfってそこまとめようとしてるように感じたんだがな
その視点で言うと普及しなさそうで失敗ぽいけど

ZendFrameworkに関しては、使える部分はあるんだけどね。
ともすればRouterやControllerあたりに目を奪われて、ライブラリ
部分の評価がおざなりになってしまったりする。

例えばCIに持ち込むとかすればいいし、双方ともそれが簡単に
出来るように作ってはあるんだけど、その時に何というか気持ち悪い

何故かと考えたが、クラス・変数・関数・ファイル名等の命名規則が、
分散しすぎているせいもあるなあというのが最近の実感。
異質な気持ち悪さがあるのは、きっと命名規則等も分散して

>>832
最後の行はゴミｗ 消したい

5.3の名前空間使えるようになったら少しはマシになるかな

>>834
多分、それが普及するまでまた３年くらいかかるんじゃね？
名前空間全開で使ってると使用者が増えないという、何という二の舞ｗ

んで、5.2のサポート終了まで引っ張るとか。

3と4と5で文法や仕様が大きく変わって、全部に対応するライブラリやフレームワークを構築するのが困難。

3とかあり得ないし、4に対応するものを新しく書く必要もない、と思うけどね
4はそれこそ、今までの遺産でがんばれば良いじゃない

幕の内弁当のようにいろいろな具が詰まったフレームワークを、いったんバラバラの具に分解して
自由に組み合わせて食べられるとウマー？

時間があったら、フレームワークのコードを読んでみるか…。

Perl5.0が1994年、Perl5.6でさえ2000年にリリースされてる。これが圧倒的なボリュームのCPANがあるPerlと、Pearが尻すぼみに終わり、Zendが始まりもしなかったPHPの違い。

>>838
別にそんなに難しくないし、メリットはあるとおもう。例えばZend_Pdfとか持って来たり。

lib/Zend 以下をごっそりvendor/とかにコピーしてinclude_pathを通すのが一番楽だけど、
依存に注意しながら必要なものだけを持ってくるのでも、それほど難しくない。
例外が２系統投げられるので、その辺が気になるなら対処して。

CIの場合はそれほどコアに密着したライブラリって無いので、例えばSessionとかDbとか
も、好きなものを使おうと思えば使える。Registryとか、なんでCIにないのかなって思ったし。

＃ そうすると、CIの機能をいくらか無視することにもなるかもだけど、それで幸せになれるならおｋ

で、問題はそれをやると、ソースがカオスになると。メソッドの命名規則なんか、CIはZFの
対局にいると言っても過言ではないとおもうし。
＃ クラスにprefixつけない、CamelCase嫌い、クラスファイル名でもCamelCase式と
＃ lowercase-underscore式の、独自ルールによる混在、もろもろ・・・

そこに上乗せする俺のソースはどっちで書けばすっきりするんだああ、となるよ。

DIの設定がXML地獄てSpring2.5とか使ったことないのか？
ここのアホ住人は。
今は、XMLにはほとんど記述せずにアノテーションでお手軽に記述できるんだよ。

>>842
そうやって、どんどんJava風を進めて行くわけですね。＞アノテーション
出来れば、そのメリット・デメリットを絡めたレスが欲しいなぁ。

なんでJavaで一般的なものがPHPで一般的でないか、それを、
「遅れている」等としか捉えられないのなら、少しおかしいと思っていいよｗ

>>843
842は設定ファイル云々に突っ込んでるだけでしょ

>>844
それを言うなら、XML言い出した大本の>>825では自嘲している
> 俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。

むしろ、DI派の具体的な書き込みが無いから発展しないんだろうが。

本当に、PHPでDIとかDaoとか、「これはいい！」と思って使ってる人っているの？

そもそもPHPやRubyのような動的言語には、DIみたいな回りくどい書き方は不要。
静的言語の融通の効かなさを誤魔化すために生み出されたものだし。

Tomcatの再起動とか面倒だったりするもんな。

自分のプログラム技術が上手なことに気付いた
アルゴリズム能力は知識で補えない、もって生まれた能力

>>849
オリジナルの式を組めるなら凄いな