1read 100read
2012年09月WebProg17: 【PHP】PHPフレームワーク総合スレ15 (703) TOP カテ一覧 スレ一覧 2ch元 削除依頼
PHP関連の書籍 第7版 (903)
☆ショッピングカートのCGIを作りたい!Perlで☆ (511)
webプログラマーの募集方法 (645)
アプリケーションサーバって必要? (209)
ファイルメーカーでどこまでできるウェブアプリ! (461)
CGIでショッピングカートを作るスレ (267)

【PHP】PHPフレームワーク総合スレ15


1 :2010/12/12 〜 最終レス :2012/11/02
PHPのフレームワークに関する話題用のスレッド
●国外産●
symfony
 ttp://www.symfony-project.com/
code igniter
 ttp://codeigniter.com/
Zend Framework
 ttp://framework.zend.com/manual/ja/index.html
CakePHP
 ttp://www.cakephp.org/
Yii Framework
 ttp://www.yiiframework.com/
●国産
ちいたん
 ttp://php.cheetan.net/
Ethna
 ttp://ethna.jp/
guesswork
 ttp://classic.guesswork.jp/
maple
 ttp://kunit.jp/maple/
●前スレ
【PHP】PHPフレームワーク総合スレ14
http://hibari.2ch.net/test/read.cgi/php/1253912143/

2 :
●過去スレ一覧
14http://hibari.2ch.net/test/read.cgi/php/1253912143/
13http://hibari.2ch.net/test/read.cgi/php/1237825268/
12http://hibari.2ch.net/test/read.cgi/php/1229960175/
11http://hibari.2ch.net/test/read.cgi/php/1219581817/
10http://hibari.2ch.net/test/read.cgi/php/1202521438/
. 9http://hibari.2ch.net/test/read.cgi/php/1197383840/
. 8http://hibari.2ch.net/test/read.cgi/php/1192604501/
. 7http://hibari.2ch.net/test/read.cgi/php/1181350116/
. 6http://hibari.2ch.net/test/read.cgi/php/1171896620/
. 5http://pc10.2ch.net/test/read.cgi/php/1159579507/
. 4http://pc8.2ch.net/test/read.cgi/php/1151706907/
. 3http://pc8.2ch.net/test/read.cgi/php/1145971945/
. 2http://pc8.2ch.net/test/read.cgi/php/1135847024/
. 1:http://pc8.2ch.net/test/read.cgi/php/1123608068/

3 :
頭の悪い言い争いする前にスレ立てとけ
既に実装されてしまった内容なんだから、使う使わないは案件なりで決めれ
不満があるなら開発途上の段階で割り込んでおけよと
仕様みてみたが、バックスラッシュは格好悪いけど、実装自体は普通のnamespaceじゃん
バックスラッシュは格好悪いけど、常に完全修飾名を要求されるとか、使い方知らないだけじゃ
再利用を考えたら、結局namespaceは必要だしな。バックスラッシュは格好悪いけど
ほんとバックスラッシュは格好悪いけどな
わざわざコード書く環境だけ正しいフォントに直すのも面倒だし

4 :
ハイライト
992 nobodyさん [sage] 2010/12/12(日) 03:24:51 ID:???
PHPの名前空間は、
http://www.php.net/manual/ja/language.namespaces.rationale.php
Prefix付の長いクラス名を何とかする為のアプローチに見えるな。
実際には、使用時に絶対パスで記述しないとクラス名の衝突が起こる可能性があるので、
何も解決出来ていない(結局絶対パスで記述する必要がある)
情弱は使えばいいよ。
993 nobodyさん[sage] 2010/12/12(日) 03:46:35 ID:???
なんでこいつは名前空間とパスを同一視してるの?
こんなんだからPHP使いはレベルが低いとか言われるんだよ…
994 nobodyさん [sage] 2010/12/12(日) 03:49:53 ID:???
>>993
パス=クラス名への絶対修飾子って意味ね。
Zend_Hoge_Moge と書くのも \Zned\Hoge\Moge と書くのも同じだし、
このように絶対パスで書かないとクラス衝突は防げない。
となると本来目標にかかげていた、冗長なクラス名の廃止はどうなったのかと・・・
明らかに設計ミスだろ。

5 :
995 nobodyさん [sage] 2010/12/12(日) 03:52:41 ID:???

その目的の為の名前空間でありそれは達成されてるわけだが?
5.2を切り捨てて対応してるフレームワークなりなんなりみてみろよ
綺麗に切り分けられクラス名は短くなってる
997 nobodyさん [sage] 2010/12/12(日) 04:00:46 ID:???
>>995
されてねーよ。
定義側は省略形で書けるかもしれんが、
実際に使用する側はフルパスで書かないといかんだろ。
打開策として use で別名エイリアスが付けられるが、
エイリアスが他クラスと被る可能性があるという本末転倒っぷり。
それならエイリアスなんか作らず
$className = 'Hoge\Moge\Class';
$class = new $className;
と書く方が利口。
どちらにせよ、当初の目的は果たせていない。

6 :
Zendが考えた擬似ネームスペースはもう捨てて
namespace + 新しい規約で
なんとかしろや。

7 :
既に有名なフレームワークはそうしてる
ぶっちゃけ今更感が半端無い
3年前の話題だろ…

8 :
>既に有名なフレームワークはそうしてる
symfony2.0

9 :
ZendFramework2 も namespace採用されるよ。
ただsymfony2もだけど、PEAR命名規約のアンダースコアをバックスラッシュに変えただけ感はある。
前スレ>>1000
他の言語と比較した上での発言だ。
>エイリアスが他クラスとかぶる可能性とか何を言ってるんだと言わざるを得ない
namespace project;
use lib\ClassName as ClassName;
という記述があった場合に ClassName が project\ClassName と衝突する可能性があるから、
基本的には絶対パスでの記述になる。
コンパイル時に走査してくるような言語とは使い勝手が全く違う。
>jsですらjqueryやらprototypeやら他のライブラリつかって名前空間を表現しようって風潮なのにどんだけ取り残されてるんだよ
それらは疑似名前空間で、実装ではなく規約の話だ。
PHPのアンダースコア区切りのクラス名と同類だよ。
namespaceの実装が望まれたECMA4が廃案になったのは知ってるかい?w

10 :
何で :: とかにしなかったんだろう。\だと末尾に「.php」が抜けてるような気持ち悪さが…
フレームワーク関係ないね、すまそ

11 :
サーバOSがWindowsとかだとますます混乱しそうだよね。
>>10
:: はクラス内のスタティックメソッドやプロパティやクラス内定数の参照の時に既に使ってるし、そっちとかぶるからじゃない?

12 :
メソッドだろうがプロパティだろうが名前空間だろうが
全部ピリオドにすればよかったのに

13 :
文字列連結に使ってる時点でもうダメだろ。

14 :
もう面倒だからサーバサイドJavaScriptに移行しようず

15 :
jsは言語が汚れすぎてる
オライリーですら擁護しきれずに綺麗な部分だけ使おうっていう本を出してるぐらいにねw

16 :
>>11
Perlだってスタティックメンバの参照に::使ってるけど
名前空間の区切りは::だよ。

17 :
まぁすでに実装されてしまったものだし諦めるしか

18 :
言語仕様もエンジンの実装もドロドロに汚れちゃってるからなPHPは。
namespaceが中途半端な機能で、
区切り文字がバックスラッシュになったのも、
fainallyが実装されないのも、
ZendEngine2への実装が困難だからだよ。

19 :
なんでfinally実装できないの?

20 :
Lithiumのその後を知ってる人いる?
そろそろリリースかな

21 :
>>19
単純に技術的な問題。
良い実装案が出れば、実装したいと開発者は言っている。

22 :
へ?構築するスキルがないってだけ?ZendEngineの問題でなく?

23 :
>>22
ZendEngineに実装する上での技術的な問題だよ。

24 :
だからそれどういう問題?

25 :
>>24
だから、技術的な問題だよ。
興味あるならPHP自体のソースコードを読めばいいよ。

26 :
そういう理由じゃないだろ
http://bugs.php.net/bug.php?id=32100

27 :
Bjarne Stroustrup's C++ Style and Technique FAQ
Why doesn't C++ provide a "finally" construct?
http://www2.research.att.com/~bs/bs_faq2.html#finally

28 :
finally、無いよりもあったほうがいい。それは間違いない。finallyの導入にどれくらい開発コストがかかるかは知らないが。

29 :
スクリプト言語にfinallyねぇ
中々面白いギャグだ
マジだったらプログラムを一からやり直して欲しいレベル

30 :
>>26-27
で、どういう理由なん?

31 :
javascript には finally あるんだが

32 :
RubyにもPythonにもfinally相当あるよ。ついでにPerl6にもある。

33 :
>>25
ワロス 知ったか乙w

34 :
英語の読めない俺の為に簡単に訳してくれ

35 :
どこが分からんの?

36 :
>>35
http://bugs.php.net/bug.php?id=32100
return文との兼ね合いで、構文が複雑になるから実装しなかったって事?
それとも技術的な問題?

37 :
全部訳せとな?

38 :
>>37
散々議論されたってのは読み取れたけど、
最終的に何故実装されなかったのかが読み取れませんでした先生。

39 :
声の大きな人に限って結論をぼかすよなw

40 :
26は最初か2番目に出てくるコードで代用できると
27はリソースの開放は利用側じゃなくて利用されるデストラクタで実装すべきという主張。C だが

41 :
http://gihyo.jp/news/interview/2010/rasmus?page=3
「finallyも,もしよい実装があれば追加されるかも知れません。」
PHP構文的に排除したのでは無く、実装が困難だから実装されていないだけだ
>>26-27
お前英語読めないだろ?
せめてメーリングリストのログ持って来いよ

42 :
C++にfinallyが無いのと同じ理由。

43 :
>>42
ワロス、ギブミーソース

44 :
よい実装があれば可能=技術的に困難、なのか?

45 :
>>41
おまえその日本語読めてない。
空気も英語も読めてないのにメーリングリスト読めないだろ

46 :
>>45
空気読めてないのはお前だろw 顔赤くしてないで該当メーリングリストのソースを示せよ。
大垣:
 実装して欲しい,実装しておくべき機能は思い浮かびますか?
Rasmus:
 オブジェクト指向プログラミングのサポートについては実装されるでしょう
 traitsにはよい実装があるのでPHP 5.4に含まれることになるでしょう。
 finallyも,もしよい実装があれば追加されるかも知れません。
どう読んでも、実装の問題。

47 :
よい実装ってどういうこと?

48 :
プライオリティが低いってだけじゃないの?

49 :
>>47
そのままの意味だよ。
実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい。
>>48
どこにプライオリティの話が書いてあるんだw

50 :
>>49
However namespaces are much harder to implement yet I think finally is relatively straightforward since we can already emulate it using try/catch, but with the quirks.
namespaceの方が実装難しいと書いてあるんだが?

51 :
>>50
ん?それは誰の発言?

52 :
実際finallyが必要になる場面って、どういうのがあるだろう
そもそもfinallyの代替になる方法、そんなに面倒?

53 :
実際namespaceが必要になる場面って、どういうのがあるだろう
そもそもnamespaceの代替になる方法、そんなに面倒?

54 :
>>49
>実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい
のソースは?

55 :
例えば、アクセス制御だって、アンダーバーから始まるメソッドはプライベート扱いにするってルールでコーディングすれば、publicやprivateは不要。
が、そんなローカルルールに頼るよりも言語機能を使った方が良い。
PHPでPearが盛り上がらない理由の1つは、PHPにネームスペースやパッケージがなかったからだと思う。

56 :
PEARが盛り上がら・・・ない?

57 :
PHPって、WAFがフルスクラッチ・フルスタックなのばっかだからな。
PEAR::DBとSmartyくらいか。どっちもPHP4全盛時で、今じゃ大して使われてないな。
後は、日本だけでNet_UserAgent_Mobileくらいか。

58 :
PHPのnamespaceの一番ダメな所は、標準で規約が無いところ。
・パッケージとディレクトリ構造は一致
・クラスファイル名はクラス名+.php
・パッケージ名はドメイン名+プロジェクト名を接頭とし、Camelcaseで記述する
・クラス名はCamelcaseで記述する
のような規約があり、かつuse文でオート(Lazy)ロードに対応
くらいして欲しかった。

自分で実装出来るが、
標準でuse構文が上記に対応していたら、標準化が進むのになぁと思ったりした

59 :
一番ダメなのは5.0の時に出さなかったところだと思う

60 :
C言語の一番ダメなところは、
ネームスペースがなかったり
クラスがなかったり、
例外がなかったり

61 :
>>60
唐突になにいいだすんかとおもうが、
高級アセンブリ言語だからあれでいいのです。

62 :
N88BASICこそが究極であり至高ですよとベーマガ読者は言う。

63 :
>>60
だからC++が出来たんだろ?馬鹿なの?

64 :
C++って最初は例外もネームスペースもなかったの知ってる?

65 :
ま、名前空間とは別に、パッケージの仕組みも合った方が良いな。

66 :
名前空間、パッケージに関しては
やはり色々考えられているPerlの方が上だな。

67 :
自社フレームワークを使ってるところが多い気がするが、
自社のフレームワーク開発すべき?

68 :
必要ない

69 :
>>68
俺もそう思う。バグだらけのFWを、開発した奴はスキルアップになったかもしれんが、
それを使わされる方はマジたまらんわー。
他の人の意見も求む!

70 :
必要ない

71 :
半端なFW使うよりかは、もともとある奴をちゃんと検証して
バージョンアップしながら使ってくほうが後々考えると有益
ちょっとしたことのためにFWいじくって対応とかアホなことすると、
大抵はあとで酷いことになる

72 :
既存のフレームワークを、自分らの使いやすいようにラップするケースは多々ある。
一からフレームワークを作るのは、勉強目的以外ではあまりメリット無いかな・・・

73 :
>>71
>ちょっとしたことのためにFWいじくって対応とかアホなことすると、
あるある。ありすぎて困る。
「それはフレームワークじゃねぇ、ただのライブラリだ!」
と言っても、社内のPHP屋は理解出来ない。
PHPでOSSのフレームワーク使ってない(使い方わからない)時点で、
その程度だわな・・・

74 :
あ、普段はASP.NETやってます。
あれは立派なフレームワークな反面、
社内製フレームがクソすぎて・・・・
(なぜOSSのフレームワークを作らないのか・・・)
という背景があることをいちおう言っておきます。

75 :
(なぜOSSのフレームワークを”使わないか”)だった

76 :
>>73
PHPだけでいえば、CakeぐらいはできるがSymfonyはさすがにできないという、
中途半端な技術者が社内製フレームワークを作ってる気がする

77 :
>>76
SymfornyはCakeに比べて設計が難しいという意味?

78 :
http://www.google.com/trends?q=cakephp%2Csymfony%2Czend+framework%2Cyii
トレンドでみるとyiiが順調に伸びているが、来年もこのままの勢いを保つか。

79 :
これはtwitterをもとにした集計によるトレンド
PHP Frameworks Trends
The data below is generated automatically from twitter
http://trends.phpmagazine.net/frameworks/

80 :
名前空間があってよかったことってなんかある?

81 :
英語、新しいものダメダメな日本のPHPerにはウケわるいけど
お外じゃYiiは結構人気でてるっぽいよね

82 :
http://www.google.co.jp/trends?q=%22Yii+Framework%22%2CCakePHP%2CSymfony%2C%22Zend+Framework%22&ctab=0&geo=all&date=all&sort=0
・・・どこが?

83 :
>>82
Yii って他の意味あるのか? Yii Frameworkでググル意味は?

84 :
>>82
おまえは何がしたいんよ。

85 :
新しいモノ=良いモノとも限らないし、、
今の日本の保守的でグダグダなWEB開発業界を考えると、
枯れてリソースの揃いきったFWを深く使いこなす方が得なんだろうね。
既存のFWを捨てて、新しいFWに移行する明確なメリットデメリットが示せない限りね・・・

86 :
>>83
yii -phpの検索結果:約 9,160,000 件 (0.07 秒)
http://www.google.com/search?hl=ja&safe=off&q=Yii+-php&aq=f&aqi=&aql=&oq=&gs_rfai=
>>84
人気出てるというから検証しただけ。

87 :
それだったらこうだろ
http://www.google.co.jp/trends?q=%22Yii+-php%22%2CCakePHP+-php%2CSymfony+-php%2C%22Zend+Framework+-php%22&ctab=0&geo=all&date=all&sort=0

88 :
>>86
Yii の検索結果:約 5,200,000 件 (0.04 秒)
しかし"Yii"のキーワードだけで検索するよりも多いってのがな〜w
一体何の検証になってるんだか
・マイナス検索をすると検索結果が増える場合があります
https://groups.google.com/group/google_web_search_help_jp-troubleshooting/browse_thread/thread/0dc3791da3bb7dde?hl=ja

89 :
Yii Frameworkの他に"Yii"のつく目新しいものなんてないだろ、たぶん。
Yiiフレームワークが登場してから"Yii"のトレンドが上昇してるのは、
明らかにYiiフレームワークの成果だろ。

90 :
>>85
yiiのパフォーマンス優位は検証されてるけど
http://www.yiiframework.com/performance/
http://www.sheldmandu.com/php/php-mvc-frameworks/php-mvc-framework-performance-part-1

91 :
こんなのもあるよ。
http://erickennedy.org/Drupal-7-Reasons-to-Switch

92 :
今後もPHPが続くとしたら、新規の際の選択肢には入れたほうがいいとは思う

93 :
蓄積された情報やノウハウ、学習コストを含めるとYiiはまだまだかな。
職業PGが増えてる昨今、まともな学習教材が無いと開発者の足並みが揃わない。

>>90
Hello Worldベンチマーク・・・

94 :
>Hello Worldベンチマーク・・・
何が言いたいの?
検証に問題があるならはっきり指摘して

95 :
職業PGなんて教材があっても
多分こうだろう的な、なんも考えてない場当たり実装を次々編み出してくし
日本語で説明されてるコピペできる参考例が多くないと、確かに難しいだろうなw

96 :
symfony2はYiiより速いらしいよ。
設定がめんどいようだけど。
http://symfony-reloaded.org/fast
http://www.symfony.gr.jp/blog/20100622-the-state-of-symfony2-1

97 :
symfonyはsfFormがどうもだめだ…
symfony2で変わったのかな。

98 :
>>94
Hello Worldの値なんて理論値みたいなもので、
実際の実用環境では他のロジック部分がボトルネックになるから、ほとんど意味の無い値って事。
上の比較ではsymfonyが数倍遅いと錯覚してしまうが、
実際に作るコンテンツ内容、コーディング方法、ファイルI/O、DB処理等の方が遙かに比重が高い。
開発者全員が完璧な最適化を行えるのなら、フレームワークのオーバーヘッドを考慮するのも有意義かもしれんが、
現実的では無いし、大抵は枯れた技術の方が最適な実装が出来るし、学習コストも低い。
その浮いたコストをハードウェアやネットワークに回す方が遙かにパフォーマンスは上がる。
それ以上のチューニングを行う場合は、フレームワーク自体導入しない事の方が多い。

99 :
地味にYiiスレ出来てんのな
で、このスレをディスってんのなw

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼
くだらない質問でも偉そうに聞いていいスレ (397)
☆ショッピングカートのCGIを作りたい!Perlで☆ (511)
WebLogic に詳しい人いません。 (621)
ソーシャルネットワーキングのシステムを作ろう! (598)
サーバーサイドJavaScript総合 (242)
ショッピングカート総合スレ (416)
--log9.info------------------
干 さ れ メ ン の 涙 (525)
【AKB48】藤江れいな応援スレ☆84【れいにゃん】 (568)
【AKB/SKE】北原里英応援スレ☆Part596【きたりえ】 (210)
【AKB48】森川彩香応援スレ☆11【あーやロイド】 (999)
【AKB48】チームKが最強すぎる★4.1 (854)
松井玲奈たむが順調に鉄道ヲタになってる (716)
【乃木坂46】西野七瀬応援スレ★12【ななせまる】 (439)
乃木坂46で一番お気に入りのメンバーは誰?2 (705)
【HKT48】谷 真理佳 応援スレ 1【2期生】 (602)
【SKE48】秦佐和子応援スレ☆154【しゃわこ】 (718)
【乃木坂46】能條愛未応援スレ★3【あみあみ】 (260)
康は何故選挙で珠理奈>玲奈なんてバレバレ操作したの (480)
篠田麻里子&高橋みなみ (909)
【AKB48】仁藤萌乃応援スレ104【振入れ上腕仁藤筋】 (407)
NMB48 3期応援スレッド★11【teamB2】 (984)
HKTで一番可愛いか子ば決めるバイ (747)
--log55.com------------------
チャンネル桜 156【デフレ深刻化】
クイズ!脳ベルSHOW5
地上波デジタルの遠距離受信 その21
【来年こそ東京へ】 NHK大阪・井田香菜子アナ3 【関西845】
NHKニュースおはよう日本 Part5
【おとうさんといっしょ】竹内夢 1駅目【ゆめちゃん】
連続テレビ小説『スカーレット』 は何故、超歴史的な大コケをしたのか?
■ NHK受信料・受信契約総合スレッド 296■