トップページ⇒php
989コメント277KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2010/12/12(日) 10:47:08ID:???
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/
0002nobodyさん2010/12/12(日) 10:47:46ID:???
●過去スレ一覧
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/
0003nobodyさん2010/12/12(日) 11:19:10ID:???
頭の悪い言い争いする前にスレ立てとけ
既に実装されてしまった内容なんだから、使う使わないは案件なりで決めれ
不満があるなら開発途上の段階で割り込んでおけよと

仕様みてみたが、バックスラッシュは格好悪いけど、実装自体は普通のnamespaceじゃん
バックスラッシュは格好悪いけど、常に完全修飾名を要求されるとか、使い方知らないだけじゃ
再利用を考えたら、結局namespaceは必要だしな。バックスラッシュは格好悪いけど
ほんとバックスラッシュは格好悪いけどな
わざわざコード書く環境だけ正しいフォントに直すのも面倒だし
0004nobodyさん2010/12/12(日) 11:57:31ID:???
ﾊｲﾗｲﾄ

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 と書くのも同じだし、
このように絶対パスで書かないとクラス衝突は防げない。

となると本来目標にかかげていた、冗長なクラス名の廃止はどうなったのかと･･･
明らかに設計ミスだろ。
0005nobodyさん2010/12/12(日) 11:57:47ID:???
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;
と書く方が利口。

どちらにせよ、当初の目的は果たせていない。
0006nobodyさん2010/12/12(日) 12:11:41ID:???
Zendが考えた擬似ネームスペースはもう捨てて
namespace + 新しい規約で
なんとかしろや。
0007nobodyさん2010/12/12(日) 21:55:13ID:???
既に有名なフレームワークはそうしてる
ぶっちゃけ今更感が半端無い
3年前の話題だろ…
0008nobodyさん2010/12/13(月) 04:12:37ID:???
＞既に有名なフレームワークはそうしてる
symfony2.0
0009nobodyさん2010/12/13(月) 19:03:50ID:???
ZendFramework2 も namespace採用されるよ。
ただsymfony2もだけど、PEAR命名規約のアンダースコアをバックスラッシュに変えただけ感はある。

前スレ>>1000
他の言語と比較した上での発言だ。

＞エイリアスが他クラスとかぶる可能性とか何を言ってるんだと言わざるを得ない
namespace project;
use lib\ClassName as ClassName;

という記述があった場合に ClassName が project\ClassName と衝突する可能性があるから、
基本的には絶対パスでの記述になる。
コンパイル時に走査してくるような言語とは使い勝手が全く違う。

＞jsですらjqueryやらprototypeやら他のライブラリつかって名前空間を表現しようって風潮なのにどんだけ取り残されてるんだよ
それらは疑似名前空間で、実装ではなく規約の話だ。
PHPのアンダースコア区切りのクラス名と同類だよ。
namespaceの実装が望まれたECMA4が廃案になったのは知ってるかい？ｗ
0010nobodyさん2010/12/13(月) 19:11:09ID:???
何で :: とかにしなかったんだろう。\だと末尾に「.php」が抜けてるような気持ち悪さが…
フレームワーク関係ないね、すまそ
0011nobodyさん2010/12/13(月) 19:37:03ID:???
サーバOSがWindowsとかだとますます混乱しそうだよね。

>>10
:: はクラス内のスタティックメソッドやプロパティやクラス内定数の参照の時に既に使ってるし、そっちとかぶるからじゃない？
0012nobodyさん2010/12/13(月) 19:57:00ID:???
メソッドだろうがプロパティだろうが名前空間だろうが
全部ピリオドにすればよかったのに
0013nobodyさん2010/12/13(月) 22:06:38ID:???
文字列連結に使ってる時点でもうダメだろ。
0014nobodyさん2010/12/13(月) 23:31:53ID:???
もう面倒だからサーバサイドJavaScriptに移行しようず
0015nobodyさん2010/12/13(月) 23:54:10ID:???
jsは言語が汚れすぎてる
オライリーですら擁護しきれずに綺麗な部分だけ使おうっていう本を出してるぐらいにねｗ
0016nobodyさん2010/12/14(火) 00:52:00ID:???
>>11
Perlだってスタティックメンバの参照に::使ってるけど
名前空間の区切りは::だよ。
0017nobodyさん2010/12/14(火) 01:58:34ID:???
まぁすでに実装されてしまったものだし諦めるしか
0018nobodyさん2010/12/14(火) 03:45:08ID:???
言語仕様もエンジンの実装もドロドロに汚れちゃってるからなPHPは。

namespaceが中途半端な機能で、
区切り文字がバックスラッシュになったのも、
fainallyが実装されないのも、

ZendEngine2への実装が困難だからだよ。
0019nobodyさん2010/12/14(火) 07:54:18ID:???
なんでfinally実装できないの？
0020nobodyさん2010/12/14(火) 16:44:36ID:???
Lithiumのその後を知ってる人いる？
そろそろリリースかな
0021nobodyさん2010/12/15(水) 00:20:25ID:???
>>19
単純に技術的な問題。
良い実装案が出れば、実装したいと開発者は言っている。
0022nobodyさん2010/12/15(水) 01:19:20ID:???
へ？構築するスキルがないってだけ？ZendEngineの問題でなく？
0023nobodyさん2010/12/15(水) 01:58:32ID:???
>>22
ZendEngineに実装する上での技術的な問題だよ。
0024nobodyさん2010/12/15(水) 02:14:25ID:???
だからそれどういう問題？
0025nobodyさん2010/12/15(水) 03:14:43ID:???
>>24
だから、技術的な問題だよ。
興味あるならPHP自体のソースコードを読めばいいよ。
0026nobodyさん2010/12/15(水) 06:24:51ID:mlC32vdu
そういう理由じゃないだろ
http://bugs.php.net/bug.php?id=32100
0027nobodyさん2010/12/15(水) 06:35:05ID:mlC32vdu
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
0028nobodyさん2010/12/15(水) 08:08:22ID:???
finally、無いよりもあったほうがいい。それは間違いない。finallyの導入にどれくらい開発コストがかかるかは知らないが。
0029nobodyさん2010/12/15(水) 08:15:57ID:???
スクリプト言語にfinallyねぇ
中々面白いギャグだ
マジだったらプログラムを一からやり直して欲しいレベル
0030nobodyさん2010/12/15(水) 08:56:06ID:???
>>26-27
で、どういう理由なん？
0031nobodyさん2010/12/15(水) 20:09:51ID:???
javascript には finally あるんだが
0032nobodyさん2010/12/15(水) 21:17:34ID:???
RubyにもPythonにもfinally相当あるよ。ついでにPerl6にもある。
0033nobodyさん2010/12/15(水) 21:25:47ID:???
>>25
ﾜﾛｽ　知ったか乙ｗ
0034nobodyさん2010/12/15(水) 22:28:49ID:???
英語の読めない俺の為に簡単に訳してくれ
0035nobodyさん2010/12/15(水) 22:29:38ID:???
どこが分からんの？
0036nobodyさん2010/12/15(水) 22:39:21ID:???
>>35
http://bugs.php.net/bug.php?id=32100
return文との兼ね合いで、構文が複雑になるから実装しなかったって事？
それとも技術的な問題？
0037nobodyさん2010/12/15(水) 22:40:05ID:???
全部訳せとな？
0038nobodyさん2010/12/15(水) 22:59:50ID:???
>>37
散々議論されたってのは読み取れたけど、
最終的に何故実装されなかったのかが読み取れませんでした先生。
0039nobodyさん2010/12/16(木) 00:33:53ID:???
声の大きな人に限って結論をぼかすよなｗ
0040nobodyさん2010/12/16(木) 01:20:05ID:???
26は最初か2番目に出てくるコードで代用できると
27はリソースの開放は利用側じゃなくて利用されるデストラクタで実装すべきという主張。C だが
0041nobodyさん2010/12/16(木) 01:54:17ID:???
http://gihyo.jp/news/interview/2010/rasmus?page=3
「finallyも，もしよい実装があれば追加されるかも知れません。」
PHP構文的に排除したのでは無く、実装が困難だから実装されていないだけだ

>>26-27
お前英語読めないだろ？
せめてメーリングリストのログ持って来いよ
0042nobodyさん2010/12/16(木) 02:32:06ID:???
C++にfinallyが無いのと同じ理由。
0043nobodyさん2010/12/16(木) 03:44:17ID:???
>>42
ﾜﾛｽ、ｷﾞﾌﾞﾐｰｿｰｽ
0044nobodyさん2010/12/16(木) 07:26:50ID:???
よい実装があれば可能＝技術的に困難、なのか？
0045nobodyさん2010/12/16(木) 08:13:53ID:???
>>41
おまえその日本語読めてない。
空気も英語も読めてないのにメーリングリスト読めないだろ
0046nobodyさん2010/12/16(木) 11:55:51ID:???
>>45
空気読めてないのはお前だろｗ　顔赤くしてないで該当メーリングリストのソースを示せよ。

大垣：
　実装して欲しい，実装しておくべき機能は思い浮かびますか？

Rasmus：
　オブジェクト指向プログラミングのサポートについては実装されるでしょう
　traitsにはよい実装があるのでPHP 5.4に含まれることになるでしょう。
　finallyも，もしよい実装があれば追加されるかも知れません。

どう読んでも、実装の問題。
0047nobodyさん2010/12/16(木) 20:01:14ID:???
よい実装ってどういうこと？
0048nobodyさん2010/12/16(木) 20:23:29ID:???
プライオリティが低いってだけじゃないの？
0049nobodyさん2010/12/17(金) 00:29:50ID:???
>>47
そのままの意味だよ。
実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい。

>>48
どこにプライオリティの話が書いてあるんだｗ
0050nobodyさん2010/12/17(金) 00:33:18ID:???
>>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の方が実装難しいと書いてあるんだが？
0051nobodyさん2010/12/17(金) 01:54:36ID:???
>>50
ん？それは誰の発言？
0052nobodyさん2010/12/17(金) 01:55:07ID:???
実際finallyが必要になる場面って、どういうのがあるだろう
そもそもfinallyの代替になる方法、そんなに面倒？
0053nobodyさん2010/12/17(金) 04:00:30ID:???
実際namespaceが必要になる場面って、どういうのがあるだろう
そもそもnamespaceの代替になる方法、そんなに面倒？
0054nobodyさん2010/12/17(金) 07:14:13ID:???
>>49
>実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい
のソースは？
0055nobodyさん2010/12/17(金) 09:59:22ID:???
例えば、アクセス制御だって、アンダーバーから始まるメソッドはプライベート扱いにするってルールでコーディングすれば、publicやprivateは不要。
が、そんなローカルルールに頼るよりも言語機能を使った方が良い。
PHPでPearが盛り上がらない理由の1つは、PHPにネームスペースやパッケージがなかったからだと思う。
0056nobodyさん2010/12/17(金) 11:09:01ID:???
PEARが盛り上がら･･･ない？
0057nobodyさん2010/12/17(金) 12:19:50ID:???
PHPって、WAFがフルスクラッチ・フルスタックなのばっかだからな。
PEAR::DBとSmartyくらいか。どっちもPHP4全盛時で、今じゃ大して使われてないな。
後は、日本だけでNet_UserAgent_Mobileくらいか。
0058nobodyさん2010/12/17(金) 12:33:27ID:???
PHPのnamespaceの一番ダメな所は、標準で規約が無いところ。

・パッケージとディレクトリ構造は一致
・クラスファイル名はクラス名+.php
・パッケージ名はドメイン名+プロジェクト名を接頭とし、Camelcaseで記述する
・クラス名はCamelcaseで記述する

のような規約があり、かつuse文でオート（Lazy）ロードに対応
くらいして欲しかった。


自分で実装出来るが、
標準でuse構文が上記に対応していたら、標準化が進むのになぁと思ったりした
0059nobodyさん2010/12/17(金) 13:57:30ID:???
一番ダメなのは5.0の時に出さなかったところだと思う
0060nobodyさん2010/12/18(土) 10:24:28ID:???
C言語の一番ダメなところは、

ネームスペースがなかったり
クラスがなかったり、
例外がなかったり
0061nobodyさん2010/12/18(土) 11:39:11ID:???
>>60
唐突になにいいだすんかとおもうが、
高級アセンブリ言語だからあれでいいのです。
0062nobodyさん2010/12/18(土) 13:01:19ID:???
N88BASICこそが究極であり至高ですよとベーマガ読者は言う。
0063nobodyさん2010/12/19(日) 00:45:35ID:???
>>60
だからC++が出来たんだろ？馬鹿なの？
0064nobodyさん2010/12/19(日) 11:24:03ID:???
C++って最初は例外もネームスペースもなかったの知ってる？
0065nobodyさん2010/12/19(日) 12:10:21ID:???
ま、名前空間とは別に、パッケージの仕組みも合った方が良いな。
0066nobodyさん2010/12/20(月) 04:22:59ID:???
名前空間、パッケージに関しては
やはり色々考えられているPerlの方が上だな。
0067nobodyさん2010/12/23(木) 14:23:44ID:???
自社フレームワークを使ってるところが多い気がするが、
自社のフレームワーク開発すべき？
0068nobodyさん2010/12/23(木) 15:24:40ID:???
必要ない
0069nobodyさん2010/12/23(木) 15:41:39ID:???
>>68
俺もそう思う。バグだらけのFWを、開発した奴はスキルアップになったかもしれんが、
それを使わされる方はマジたまらんわー。

他の人の意見も求む！
0070nobodyさん2010/12/23(木) 15:45:19ID:???
必要ない
0071nobodyさん2010/12/23(木) 16:38:01ID:???
半端なFW使うよりかは、もともとある奴をちゃんと検証して
バージョンアップしながら使ってくほうが後々考えると有益
ちょっとしたことのためにFWいじくって対応とかアホなことすると、
大抵はあとで酷いことになる
0072nobodyさん2010/12/23(木) 20:37:52ID:???
既存のフレームワークを、自分らの使いやすいようにラップするケースは多々ある。
一からフレームワークを作るのは、勉強目的以外ではあまりメリット無いかな・・・
0073nobodyさん2010/12/25(土) 05:58:05ID:???
>>71
>ちょっとしたことのためにFWいじくって対応とかアホなことすると、
あるある。ありすぎて困る。
「それはフレームワークじゃねぇ、ただのライブラリだ！」
と言っても、社内のPHP屋は理解出来ない。
PHPでOSSのフレームワーク使ってない(使い方わからない)時点で、
その程度だわな・・・
■ このスレッドは過去ログ倉庫に格納されています