のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,653,115人
昨日:no data人
今日:
最近の注目
人気の最安値情報

元スレ【PHP】フレームワークについて語るスレ10【総合】

php覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

801 = :

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

802 = :

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

804 = :

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

805 = :

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

806 = :

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

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

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

807 = :

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

808 = :

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

809 = :

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

810 = :

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

811 = :

>>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());

812 = :

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

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

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

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

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

詳しい人、解説頼む

813 = :

時代はSingletonなのか? 

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

814 = :

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

815 = :

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

816 = :

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

817 = :

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

818 = :

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

819 = :

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

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

820 = :

だーめっ☆

821 = :

>>816
> ほぼ1択なのにPHPは乱立してんの?

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

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

822 = :

>>819
ググれカス

823 = :

話についていけない!
Javaを勉強しないといけませんか?^^

824 = :

>>823
やさしいJAVA

825 = :

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

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

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

826 = :

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

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

827 = :

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

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

828 = :

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

829 = :

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

831 = :

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

832 = :

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

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

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

833 = :

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

834 = :

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

835 = :

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

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

837 = :

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

839 = :

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

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

840 = :

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

841 = :

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

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

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

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

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

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

842 = :

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

843 = :

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

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

844 = :

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

845 = :

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

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

846 = :

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

847 = :

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

849 :

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

850 :

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


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド


トップメニューへ / →のくす牧場書庫について