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

1 名前：nobodyさん mailto:sage [2010/12/12(日) 10:47:08 ID:???] 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 hibari.2ch.net/test/read.cgi/php/1253912143/ 9 名前：nobodyさん mailto:sage [2010/12/13(月) 19:03:50 ID:???] ZendFramework2 も namespace採用されるよ。 ただsymfony2もだけど、PEAR命名規約のアンダースコアをバックスラッシュに変えただけ感はある。 前スレ>>1000 他の言語と比較した上での発言だ。 ＞エイリアスが他クラスとかぶる可能性とか何を言ってるんだと言わざるを得ない namespace project; use lib\ClassName as ClassName; という記述があった場合に ClassName が project\ClassName と衝突する可能性があるから、 基本的には絶対パスでの記述になる。 コンパイル時に走査してくるような言語とは使い勝手が全く違う。 ＞jsですらjqueryやらprototypeやら他のライブラリつかって名前空間を表現しようって風潮なのにどんだけ取り残されてるんだよ それらは疑似名前空間で、実装ではなく規約の話だ。 PHPのアンダースコア区切りのクラス名と同類だよ。 namespaceの実装が望まれたECMA4が廃案になったのは知ってるかい？ｗ 10 名前：nobodyさん mailto:sage [2010/12/13(月) 19:11:09 ID:???] 何で :: とかにしなかったんだろう。\だと末尾に「.php」が抜けてるような気持ち悪さが… フレームワーク関係ないね、すまそ 11 名前：nobodyさん mailto:sage [2010/12/13(月) 19:37:03 ID:???] サーバOSがWindowsとかだとますます混乱しそうだよね。 >>10 :: はクラス内のスタティックメソッドやプロパティやクラス内定数の参照の時に既に使ってるし、そっちとかぶるからじゃない？ 12 名前：nobodyさん mailto:sage [2010/12/13(月) 19:57:00 ID:???] メソッドだろうがプロパティだろうが名前空間だろうが 全部ピリオドにすればよかったのに 13 名前：nobodyさん mailto:sage [2010/12/13(月) 22:06:38 ID:???] 文字列連結に使ってる時点でもうダメだろ。 14 名前：nobodyさん mailto:sage [2010/12/13(月) 23:31:53 ID:???] もう面倒だからサーバサイドJavaScriptに移行しようず 15 名前：nobodyさん mailto:sage [2010/12/13(月) 23:54:10 ID:???] jsは言語が汚れすぎてる オライリーですら擁護しきれずに綺麗な部分だけ使おうっていう本を出してるぐらいにねｗ 16 名前：nobodyさん mailto:sage [2010/12/14(火) 00:52:00 ID:???] >>11 Perlだってスタティックメンバの参照に::使ってるけど 名前空間の区切りは::だよ。 17 名前：nobodyさん mailto:sage [2010/12/14(火) 01:58:34 ID:???] まぁすでに実装されてしまったものだし諦めるしか 18 名前：nobodyさん mailto:sage [2010/12/14(火) 03:45:08 ID:???] 言語仕様もエンジンの実装もドロドロに汚れちゃってるからなPHPは。 namespaceが中途半端な機能で、 区切り文字がバックスラッシュになったのも、 fainallyが実装されないのも、 ZendEngine2への実装が困難だからだよ。 19 名前：nobodyさん mailto:sage [2010/12/14(火) 07:54:18 ID:???] なんでfinally実装できないの？ 20 名前：nobodyさん mailto:sage [2010/12/14(火) 16:44:36 ID:???] Lithiumのその後を知ってる人いる？ そろそろリリースかな 21 名前：nobodyさん mailto:sage [2010/12/15(水) 00:20:25 ID:???] >>19 単純に技術的な問題。 良い実装案が出れば、実装したいと開発者は言っている。 22 名前：nobodyさん mailto:sage [2010/12/15(水) 01:19:20 ID:???] へ？構築するスキルがないってだけ？ZendEngineの問題でなく？ 23 名前：nobodyさん mailto:sage [2010/12/15(水) 01:58:32 ID:???] >>22 ZendEngineに実装する上での技術的な問題だよ。 24 名前：nobodyさん mailto:sage [2010/12/15(水) 02:14:25 ID:???] だからそれどういう問題？ 25 名前：nobodyさん mailto:sage [2010/12/15(水) 03:14:43 ID:???] >>24 だから、技術的な問題だよ。 興味あるならPHP自体のソースコードを読めばいいよ。 26 名前：nobodyさん [2010/12/15(水) 06:24:51 ID:mlC32vdu] そういう理由じゃないだろ bugs.php.net/bug.php?id=32100 27 名前：nobodyさん [2010/12/15(水) 06:35:05 ID:mlC32vdu] Bjarne Stroustrup's C++ Style and Technique FAQ Why doesn't C++ provide a "finally" construct? www2.research.att.com/~bs/bs_faq2.html#finally 28 名前：nobodyさん mailto:sage [2010/12/15(水) 08:08:22 ID:???] finally、無いよりもあったほうがいい。それは間違いない。finallyの導入にどれくらい開発コストがかかるかは知らないが。 29 名前：nobodyさん mailto:sage [2010/12/15(水) 08:15:57 ID:???] スクリプト言語にfinallyねぇ 中々面白いギャグだ マジだったらプログラムを一からやり直して欲しいレベル 30 名前：nobodyさん mailto:sage [2010/12/15(水) 08:56:06 ID:???] >>26-27 で、どういう理由なん？ 31 名前：nobodyさん mailto:sage [2010/12/15(水) 20:09:51 ID:???] javascript には finally あるんだが 32 名前：nobodyさん mailto:sage [2010/12/15(水) 21:17:34 ID:???] RubyにもPythonにもfinally相当あるよ。ついでにPerl6にもある。 33 名前：nobodyさん mailto:sage [2010/12/15(水) 21:25:47 ID:???] >>25 ﾜﾛｽ　知ったか乙ｗ 34 名前：nobodyさん mailto:sage [2010/12/15(水) 22:28:49 ID:???] 英語の読めない俺の為に簡単に訳してくれ 35 名前：nobodyさん mailto:sage [2010/12/15(水) 22:29:38 ID:???] どこが分からんの？ 36 名前：nobodyさん mailto:sage [2010/12/15(水) 22:39:21 ID:???] >>35 bugs.php.net/bug.php?id=32100 return文との兼ね合いで、構文が複雑になるから実装しなかったって事？ それとも技術的な問題？ 37 名前：nobodyさん mailto:sage [2010/12/15(水) 22:40:05 ID:???] 全部訳せとな？ 38 名前：nobodyさん mailto:sage [2010/12/15(水) 22:59:50 ID:???] >>37 散々議論されたってのは読み取れたけど、 最終的に何故実装されなかったのかが読み取れませんでした先生。 39 名前：nobodyさん mailto:sage [2010/12/16(木) 00:33:53 ID:???] 声の大きな人に限って結論をぼかすよなｗ 40 名前：nobodyさん mailto:sage [2010/12/16(木) 01:20:05 ID:???] 26は最初か2番目に出てくるコードで代用できると 27はリソースの開放は利用側じゃなくて利用されるデストラクタで実装すべきという主張。C だが 41 名前：nobodyさん mailto:sage [2010/12/16(木) 01:54:17 ID:???] gihyo.jp/news/interview/2010/rasmus?page=3 「finallyも，もしよい実装があれば追加されるかも知れません。」 PHP構文的に排除したのでは無く、実装が困難だから実装されていないだけだ >>26-27 お前英語読めないだろ？ せめてメーリングリストのログ持って来いよ 42 名前：nobodyさん mailto:sage [2010/12/16(木) 02:32:06 ID:???] C++にfinallyが無いのと同じ理由。 43 名前：nobodyさん mailto:sage [2010/12/16(木) 03:44:17 ID:???] >>42 ﾜﾛｽ、ｷﾞﾌﾞﾐｰｿｰｽ 44 名前：nobodyさん mailto:sage [2010/12/16(木) 07:26:50 ID:???] よい実装があれば可能＝技術的に困難、なのか？ 45 名前：nobodyさん mailto:sage [2010/12/16(木) 08:13:53 ID:???] >>41 おまえその日本語読めてない。 空気も英語も読めてないのにメーリングリスト読めないだろ 46 名前：nobodyさん mailto:sage [2010/12/16(木) 11:55:51 ID:???] >>45 空気読めてないのはお前だろｗ　顔赤くしてないで該当メーリングリストのソースを示せよ。 大垣： 　実装して欲しい，実装しておくべき機能は思い浮かびますか？ Rasmus： 　オブジェクト指向プログラミングのサポートについては実装されるでしょう 　traitsにはよい実装があるのでPHP 5.4に含まれることになるでしょう。 　finallyも，もしよい実装があれば追加されるかも知れません。 どう読んでも、実装の問題。 47 名前：nobodyさん mailto:sage [2010/12/16(木) 20:01:14 ID:???] よい実装ってどういうこと？ 48 名前：nobodyさん mailto:sage [2010/12/16(木) 20:23:29 ID:???] プライオリティが低いってだけじゃないの？ 49 名前：nobodyさん mailto:sage [2010/12/17(金) 00:29:50 ID:???] >>47 そのままの意味だよ。 実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい。 >>48 どこにプライオリティの話が書いてあるんだｗ 50 名前：nobodyさん mailto:sage [2010/12/17(金) 00:33:18 ID:???] >>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 名前：nobodyさん mailto:sage [2010/12/17(金) 01:54:36 ID:???] >>50 ん？それは誰の発言？ 52 名前：nobodyさん mailto:sage [2010/12/17(金) 01:55:07 ID:???] 実際finallyが必要になる場面って、どういうのがあるだろう そもそもfinallyの代替になる方法、そんなに面倒？ 53 名前：nobodyさん mailto:sage [2010/12/17(金) 04:00:30 ID:???] 実際namespaceが必要になる場面って、どういうのがあるだろう そもそもnamespaceの代替になる方法、そんなに面倒？ 54 名前：nobodyさん mailto:sage [2010/12/17(金) 07:14:13 ID:???] >>49 >実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい のソースは？ 55 名前：nobodyさん mailto:sage [2010/12/17(金) 09:59:22 ID:???] 例えば、アクセス制御だって、アンダーバーから始まるメソッドはプライベート扱いにするってルールでコーディングすれば、publicやprivateは不要。 が、そんなローカルルールに頼るよりも言語機能を使った方が良い。 PHPでPearが盛り上がらない理由の1つは、PHPにネームスペースやパッケージがなかったからだと思う。 56 名前：nobodyさん mailto:sage [2010/12/17(金) 11:09:01 ID:???] PEARが盛り上がら･･･ない？ 57 名前：nobodyさん mailto:sage [2010/12/17(金) 12:19:50 ID:???] PHPって、WAFがフルスクラッチ・フルスタックなのばっかだからな。 PEAR::DBとSmartyくらいか。どっちもPHP4全盛時で、今じゃ大して使われてないな。 後は、日本だけでNet_UserAgent_Mobileくらいか。 58 名前：nobodyさん mailto:sage [2010/12/17(金) 12:33:27 ID:???] PHPのnamespaceの一番ダメな所は、標準で規約が無いところ。 ・パッケージとディレクトリ構造は一致 ・クラスファイル名はクラス名+.php ・パッケージ名はドメイン名+プロジェクト名を接頭とし、Camelcaseで記述する ・クラス名はCamelcaseで記述する のような規約があり、かつuse文でオート（Lazy）ロードに対応 くらいして欲しかった。 自分で実装出来るが、 標準でuse構文が上記に対応していたら、標準化が進むのになぁと思ったりした 59 名前：nobodyさん mailto:sage [2010/12/17(金) 13:57:30 ID:???] 一番ダメなのは5.0の時に出さなかったところだと思う 60 名前：nobodyさん mailto:sage [2010/12/18(土) 10:24:28 ID:???] C言語の一番ダメなところは、 ネームスペースがなかったり クラスがなかったり、 例外がなかったり 61 名前：nobodyさん mailto:sage [2010/12/18(土) 11:39:11 ID:???] >>60 唐突になにいいだすんかとおもうが、 高級アセンブリ言語だからあれでいいのです。 62 名前：nobodyさん mailto:sage [2010/12/18(土) 13:01:19 ID:???] N88BASICこそが究極であり至高ですよとベーマガ読者は言う。 63 名前：nobodyさん mailto:sage [2010/12/19(日) 00:45:35 ID:???] >>60 だからC++が出来たんだろ？馬鹿なの？ 64 名前：nobodyさん mailto:sage [2010/12/19(日) 11:24:03 ID:???] C++って最初は例外もネームスペースもなかったの知ってる？ 65 名前：nobodyさん mailto:sage [2010/12/19(日) 12:10:21 ID:???] ま、名前空間とは別に、パッケージの仕組みも合った方が良いな。 66 名前：nobodyさん mailto:sage [2010/12/20(月) 04:22:59 ID:???] 名前空間、パッケージに関しては やはり色々考えられているPerlの方が上だな。 67 名前：nobodyさん mailto:age [2010/12/23(木) 14:23:44 ID:???] 自社フレームワークを使ってるところが多い気がするが、 自社のフレームワーク開発すべき？ 68 名前：nobodyさん mailto:sage [2010/12/23(木) 15:24:40 ID:???] 必要ない 69 名前：nobodyさん mailto:sage [2010/12/23(木) 15:41:39 ID:???] >>68 俺もそう思う。バグだらけのFWを、開発した奴はスキルアップになったかもしれんが、 それを使わされる方はマジたまらんわー。 他の人の意見も求む！ 70 名前：nobodyさん mailto:sage [2010/12/23(木) 15:45:19 ID:???] 必要ない 71 名前：nobodyさん mailto:sage [2010/12/23(木) 16:38:01 ID:???] 半端なFW使うよりかは、もともとある奴をちゃんと検証して バージョンアップしながら使ってくほうが後々考えると有益 ちょっとしたことのためにFWいじくって対応とかアホなことすると、 大抵はあとで酷いことになる 72 名前：nobodyさん mailto:sage [2010/12/23(木) 20:37:52 ID:???] 既存のフレームワークを、自分らの使いやすいようにラップするケースは多々ある。 一からフレームワークを作るのは、勉強目的以外ではあまりメリット無いかな・・・ 73 名前：nobodyさん mailto:sage [2010/12/25(土) 05:58:05 ID:???] >>71 >ちょっとしたことのためにFWいじくって対応とかアホなことすると、 あるある。ありすぎて困る。 「それはフレームワークじゃねぇ、ただのライブラリだ！」 と言っても、社内のPHP屋は理解出来ない。 PHPでOSSのフレームワーク使ってない(使い方わからない)時点で、 その程度だわな・・・ 74 名前：73 mailto:sage [2010/12/25(土) 06:00:58 ID:???] あ、普段はASP.NETやってます。 あれは立派なフレームワークな反面、 社内製フレームがクソすぎて・・・・ （なぜOSSのフレームワークを作らないのか・・・） という背景があることをいちおう言っておきます。 75 名前：73 mailto:sage [2010/12/25(土) 06:01:48 ID:???] （なぜOSSのフレームワークを”使わないか”）だった 76 名前：nobodyさん mailto:sage [2010/12/25(土) 13:40:32 ID:???] >>73 PHPだけでいえば、CakeぐらいはできるがSymfonyはさすがにできないという、 中途半端な技術者が社内製フレームワークを作ってる気がする 77 名前：nobodyさん mailto:sage [2010/12/25(土) 14:19:58 ID:???] >>76 SymfornyはCakeに比べて設計が難しいという意味？ 78 名前：nobodyさん mailto:sage [2010/12/25(土) 20:35:21 ID:???] www.google.com/trends?q=cakephp%2Csymfony%2Czend+framework%2Cyii トレンドでみるとyiiが順調に伸びているが、来年もこのままの勢いを保つか。 79 名前：nobodyさん mailto:sage [2010/12/25(土) 20:40:16 ID:???] これはtwitterをもとにした集計によるトレンド PHP Frameworks Trends The data below is generated automatically from twitter trends.phpmagazine.net/frameworks/ 80 名前：nobodyさん mailto:sage [2010/12/26(日) 02:03:25 ID:???] 名前空間があってよかったことってなんかある？ 81 名前：nobodyさん mailto:sage [2010/12/26(日) 07:39:41 ID:???] 英語、新しいものダメダメな日本のPHPerにはウケわるいけど お外じゃYiiは結構人気でてるっぽいよね 82 名前：nobodyさん mailto:sage [2010/12/26(日) 08:18:08 ID:???] www.google.co.jp/trends?q=%22Yii+Framework%22%2CCakePHP%2CSymfony%2C%22Zend+Framework%22&ctab=0&geo=all&date=all&sort=0 ・・・どこが？ 83 名前：nobodyさん mailto:sage [2010/12/26(日) 11:02:41 ID:???] >>82 Yii って他の意味あるのか？ Yii Frameworkでググル意味は？ 84 名前：nobodyさん mailto:sage [2010/12/26(日) 11:58:57 ID:???] >>82 おまえは何がしたいんよ。 85 名前：nobodyさん mailto:sage [2010/12/26(日) 13:39:26 ID:???] 新しいモノ＝良いモノとも限らないし、、 今の日本の保守的でグダグダなWEB開発業界を考えると、 枯れてリソースの揃いきったFWを深く使いこなす方が得なんだろうね。 既存のFWを捨てて、新しいFWに移行する明確なメリットデメリットが示せない限りね･･･ 86 名前：nobodyさん mailto:sage [2010/12/26(日) 14:15:12 ID:???] >>83 yii -phpの検索結果：約 9,160,000 件 （0.07 秒） www.google.com/search?hl=ja&safe=off&q=Yii+-php&aq=f&aqi=&aql=&oq=&gs_rfai= >>84 人気出てるというから検証しただけ。 87 名前：nobodyさん mailto:sage [2010/12/26(日) 14:49:37 ID:???] それだったらこうだろ 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 名前：nobodyさん mailto:sage [2010/12/26(日) 14:58:30 ID:???] >>86 Yii　の検索結果：約 5,200,000 件 （0.04 秒） しかし"Yii"のキーワードだけで検索するよりも多いってのがな〜ｗ 一体何の検証になってるんだか ・マイナス検索をすると検索結果が増える場合があります https://groups.google.com/group/google_web_search_help_jp-troubleshooting/browse_thread/thread/0dc3791da3bb7dde?hl=ja 89 名前：nobodyさん mailto:sage [2010/12/26(日) 15:09:18 ID:???] Yii Frameworkの他に"Yii"のつく目新しいものなんてないだろ、たぶん。 Yiiフレームワークが登場してから"Yii"のトレンドが上昇してるのは、 明らかにYiiフレームワークの成果だろ。 90 名前：nobodyさん mailto:sage [2010/12/26(日) 15:17:53 ID:???] >>85 yiiのパフォーマンス優位は検証されてるけど www.yiiframework.com/performance/ www.sheldmandu.com/php/php-mvc-frameworks/php-mvc-framework-performance-part-1 91 名前：nobodyさん mailto:sage [2010/12/26(日) 15:33:41 ID:???] こんなのもあるよ。 erickennedy.org/Drupal-7-Reasons-to-Switch 92 名前：nobodyさん mailto:sage [2010/12/26(日) 16:58:09 ID:???] 今後もPHPが続くとしたら、新規の際の選択肢には入れたほうがいいとは思う 93 名前：nobodyさん mailto:sage [2010/12/26(日) 17:09:03 ID:???] 蓄積された情報やノウハウ、学習コストを含めるとYiiはまだまだかな。 職業PGが増えてる昨今、まともな学習教材が無いと開発者の足並みが揃わない。 >>90 Hello Worldベンチマーク・・・ 94 名前：nobodyさん mailto:sage [2010/12/26(日) 17:23:31 ID:???] ＞Hello Worldベンチマーク・・・ 何が言いたいの？ 検証に問題があるならはっきり指摘して 95 名前：nobodyさん mailto:sage [2010/12/26(日) 17:34:00 ID:???] 職業PGなんて教材があっても 多分こうだろう的な、なんも考えてない場当たり実装を次々編み出してくし 日本語で説明されてるコピペできる参考例が多くないと、確かに難しいだろうなｗ 96 名前：nobodyさん mailto:sage [2010/12/26(日) 17:34:29 ID:???] symfony2はYiiより速いらしいよ。 設定がめんどいようだけど。 symfony-reloaded.org/fast www.symfony.gr.jp/blog/20100622-the-state-of-symfony2-1 97 名前：nobodyさん mailto:sage [2010/12/26(日) 17:46:27 ID:???] symfonyはsfFormがどうもだめだ… symfony2で変わったのかな。 98 名前：nobodyさん mailto:sage [2010/12/26(日) 18:39:55 ID:???] >>94 Hello Worldの値なんて理論値みたいなもので、 実際の実用環境では他のロジック部分がボトルネックになるから、ほとんど意味の無い値って事。 上の比較ではsymfonyが数倍遅いと錯覚してしまうが、 実際に作るコンテンツ内容、コーディング方法、ファイルI/O、DB処理等の方が遙かに比重が高い。 開発者全員が完璧な最適化を行えるのなら、フレームワークのオーバーヘッドを考慮するのも有意義かもしれんが、 現実的では無いし、大抵は枯れた技術の方が最適な実装が出来るし、学習コストも低い。 その浮いたコストをハードウェアやネットワークに回す方が遙かにパフォーマンスは上がる。 それ以上のチューニングを行う場合は、フレームワーク自体導入しない事の方が多い。 99 名前：nobodyさん mailto:sage [2010/12/26(日) 19:30:20 ID:???] 地味にYiiスレ出来てんのな で、このスレをディスってんのなｗ 100 名前：nobodyさん mailto:sage [2010/12/26(日) 19:48:30 ID:???] 半年放置しても落ちる板じゃないしあって困るこたないんじゃね 既存のPHPFWのスレは大抵できてんじゃないかな？kohanaスレとかもあるし 101 名前：nobodyさん mailto:sage [2010/12/26(日) 20:03:18 ID:???] よーしパパLithiumスレ立てちゃうぞー 102 名前：nobodyさん mailto:sage [2010/12/26(日) 21:46:11 ID:???] Yiiは見た感じ良さそうだった。symfonyとYiiで行こうぜ。 日本人が言語やFW開発しても意味ないから、それだけはやめてくれよな。 103 名前：nobodyさん mailto:sage [2010/12/26(日) 21:52:10 ID:???] >>98 ベンチマーク自体意味無しって言ってるのね。 枯れた技術とか学習コストって言ってるのも、「英語を読めない日本人PHPer」限定の話でしょ。 フレームワークの性能評価としては関係ないね。 実際は乗り換え学習コストなんてたいしたこと無いし。 104 名前：nobodyさん mailto:sage [2010/12/26(日) 22:55:05 ID:???] >>103 Hello Worldでパフォーマンスの優位性を語ることに意味は無いって事。 静的な文字列を出力するだけのWEBアプリなんて、今日日存在しないだろう、 せめてDB接続用インスタンスを生成したり、各種ユーティリティクラスを読み込んだ上で実測しなきゃね。 ＞枯れた技術とか学習コストって言ってるのも、「英語を読めない日本人PHPer」限定の話でしょ。 逆だろ、一部の自称ギーク限定で新しいモノを導入したがっているだけでしょ。 英語読めても職業PGの応用力の無さでは、新しい物を自力で吸収するのは難しい、 ググレば日本語でかみ砕いた情報が得られるFWと、学習コストは比較にならんよ。 105 名前：nobodyさん mailto:sage [2010/12/26(日) 23:07:35 ID:???] YiiとSymfony ってどっちが学習コスト低い？Kohanaは？CakePHPは？Zend Frameworkは？ 学習コストでソートするとどんな感じ？ 106 名前：nobodyさん mailto:sage [2010/12/26(日) 23:17:34 ID:???] >>104 それははベンチマークの一番最初の疑問だろうけど、じゃあ公平な評価法は何ってこと。 Why "Hello World"の反論になってないよ。 code.google.com/p/phpmark/ 107 名前：nobodyさん mailto:sage [2010/12/26(日) 23:27:10 ID:???] >>106 ＞Why "Hello World"の反論になってないよ。 反論以前の問題。公平な方法が無いからHello World？ それなら極限までそぎ落とした俺の自作MVCフレームワークの方が数倍軽いかもね。 フレームワークとしてのパフォーマンスじゃなくて、 「HelloWorldを行うには最速」って表現ならいいんじゃない？ それでパフォーマンスの優位性語られても、まっとうなPGなら疑問を抱くだろうけど。 108 名前：nobodyさん mailto:sage [2010/12/26(日) 23:46:32 ID:???] 極論出たね。 なんでHelloWorldで”オーバーヘッドを測る”のが「HelloWorldを行うには最速」とかにすり替えるんだろう。 自作のフレームワークがここにならぶのと遜色無い機能を持ってるなら「自作MVCフレームワークの方が数倍軽いかもね。」と自慢してもいいよ。 www.phpframeworks.com/ でもそうじゃないでしょ。 109 名前：nobodyさん mailto:sage [2010/12/26(日) 23:50:30 ID:???] じゃあ他の部分は遅いのYii？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef