07/11/26 08:29:19 jFWY6ZoT
フレームワークのヴァリデーションだって結局正規表現とか書く。これはフレームワーク使わなくても同じ。
あとは数値、メールのチェックとか。これも一度作れば他で使い回せるし。
フレームワークじゃなきゃ駄目な理由はないな。
ヴァリデーション以外の部分を考えなければ。
752:nobodyさん
07/11/26 08:31:45
ヴァリデーションって、そんなに使いまわせないから。メールアドレスチェックとか全角半角とかだけ、関数にくくり出しとけばそれでいい。
ビジネスロジック部分を上手く抽出して、それをヴァリデーションでも使えるように設計する方がよほど大事。
753:733
07/11/26 09:06:15
validationの仕組みがFWに埋まってて暗黙の内に呼ばれるのって使いづらいよね。
Railsのmodelに定義するのもね・・・
画面によって違うvalidation適応したいってなることもあるし。
なんで>>751-752案に賛成。
アクションの中で明示的に自分でvalidation呼びだすで良いと思う。
754:nobodyさん
07/11/26 09:09:14
>>745
俺も俺も。ちなみにO/Rマッパーはどうしてる？
PHP用ActiveRecord(Shrupだっけ？)もあるけど重そうなのでやめ。
O/Rマッパー自動生成スクリプトを作成した。
rubyでActiveRecord使ってDBの情報吸い出して、モデルクラス出力。
find()、count()、delete()とか基本メソッドも全部自動出力でｳﾏｰ
755:nobodyさん
07/11/26 09:53:58
軽量テンプレートにフロントコントローラーで十分と言って、フレームワークじゃないかのように言った後にバリデーションとオーアールマッパもとか言えば当然のツッコミな気がするが。
自分の意見以外は受け付けなくて否定されるとすぐ熱くなるタイプだな。たまにいる。
756:nobodyさん
07/11/26 10:25:31
十分って言ってるのは既存のフレームワークを使わなくても十分って話では。
要は人の作った物だと拡張するときめんどうだったりするから、自作のがいいって話。
既存ので手のつけようのないくらい良い物なら文句はないんだけどさ。
757:nobodyさん
07/11/26 10:47:22
そりゃ自作がいいにきまってるじゃん。
758:nobodyさん
07/11/26 10:54:18
>>755
＞軽量テンプレートにフロントコントローラーで十分と言って、フレームワークじゃないかのように言った後に
フロントコントローラーから受ける仕事を、表示部分に軽量テンプレート使ってるだけだろ？
ＭＣＶ的手法な構造なだけで、このスレで議論されてるフレームワークとは別物だろ？
＞バリデーションとオーアールマッパもとか言えば当然のツッコミな気がするが。
だから、バリデーションとオーアールマッパのことが気になって突っ込み入ったんだろ？
＞自分の意見以外は受け付けなくて否定されるとすぐ熱くなるタイプだな。たまにいる。
頭大丈夫？
759:nobodyさん
07/11/26 10:56:30
↑すまんＭＶＣｗｗｗ
760:nobodyさん
07/11/26 11:12:06 WWKo0wcp
<?php
$view="index.tpl";
// 処理
$entryList=Entry:getList(10);
lnclude($view);
?>
761:nobodyさん
07/11/26 11:41:54
これはひどい
762:nobodyさん
07/11/26 17:49:37
URLﾘﾝｸ(slashdot.jp)
Rubyの世界的人気度9位に上昇でPHP脂肪ｗｗｗ
763:nobodyさん
07/11/26 17:52:36
>>762のように言語依存してる奴は相当頭が悪いのだと思う。
適材適所で使い分ければ良いだけなのにｗｗｗｗ
764:nobodyさん
07/11/26 17:54:26 g6VI9o/i
>>762
んじゃまた来月会おう。
765:nobodyさん
07/11/26 17:56:04
>>762
言語設計としては素晴らしい。けど、あのパフォーマンスの悪さは何とかならないんですか(笑)
766:nobodyさん
07/11/26 17:59:03
速度がなければマシンを買い換えればいいじゃない
767:nobodyさん
07/11/26 18:17:36
もう釣りにスルーすらできないような奴しかいなくなったのかこのスレ
768:nobodyさん
07/11/26 18:24:46 g6VI9o/i
あんたｶｺｲｲよｗ
769:nobodyさん
07/11/26 18:25:32
スルーしてる奴の存在をどうやって確かめるんだよ
スタンド使い乙
770:nobodyさん
07/11/26 19:52:37
継承使いまくりなFWのデバッグのしにくさは異常
771:nobodyさん
07/11/26 20:51:29
>>770
あ、それ同意。
みんなどうやってデバッグしてんの？
772:nobodyさん
07/11/26 21:03:23
まずおもむろに全裸になります
773:nobodyさん
07/11/26 21:23:22
そもそもC++あたりの頃の規約的に継承されたクラスを継承しちゃだめじゃないか？
774:nobodyさん
07/11/26 21:29:30
ウェブアプリでクラスを使わないと表せないようなデータはごく限られた場面だけなんだよ。たいていの場合、連想配列で十分。
775:nobodyさん
07/11/26 21:31:07
クラスの役割によるけど、3階層より深くなるのは設計ミスの可能性がある。
776:nobodyさん
07/11/26 21:35:12 g6VI9o/i
基底クラスにデバッグメソッドがあるんじゃないの？
777:nobodyさん
07/11/26 22:03:20
>>762
志村～
778:nobodyさん
07/11/26 22:06:08
>>774
バカの一つ覚えみたいに、何でもかんでもクラスにすりゃイイってわけじゃないんですね。
簡単にできることを複雑にやる必要はない＝配列で十分なデータかどうかよく考えるようにしたいと思います。＾＾
779:nobodyさん
07/11/26 22:11:32
>>771
Seleniumとかテストツールがあるじゃないですか？
URLﾘﾝｸ(www.thinkit.co.jp)
みんな、フレームワークを使ったWebアプリを構築するとき、どんなテストツールを、どんなふうに使ってますか？
→What,Howを教えて！
780:nobodyさん
07/11/26 22:13:22
ファイル一つ読み書きするのにopen(),read(),write(),close()なんてメソッド作ってますが何か
781:nobodyさん
07/11/26 22:38:38 9laXyXH+
意味あんの？
782:nobodyさん
07/11/26 22:40:14
ぺちぺよんのはなし？
783:nobodyさん
07/11/26 22:49:17
>>779
普通にPHPUnit。
HTTP関係ないテストは説明するまでもないはず。
アクション（リクエスト処理）のテストは、$_GETとか$_POSTの中に値設定して、
アクション呼び出し。そんでデータベースにちゃんと入ってるかとかテスト。
こっちはテスト用のユーティリティーを作らないといかんので準備がめんどいね。
でもやる価値はある。
PHPにもspycってYamlパーサーがあったのには助かった。
784:nobodyさん
07/11/26 23:17:58
>>783
テストデータはYAMLで書くのが楽だよな。
PHPのヒアドキュメントがもう少し洗練されていれば。
785:nobodyさん
07/11/27 20:43:47
URLﾘﾝｸ(www.rubyist.net)
ruby公式ロゴ決定でPHP嫉妬ｗｗｗ
786:nobodyさん
07/11/27 20:46:35
URLﾘﾝｸ(japan.zdnet.com)
三木谷とまつもとが結託でPHPのシェア大幅下落ｗｗｗ
787:nobodyさん
07/11/27 21:10:23
アンチRubyの工作員の仕業にしか見えません
788:nobodyさん
07/11/28 02:24:54
周知でしょ
789:nobodyさん
07/11/28 11:13:11
>>779
Seleniumは、PHPというよりHTML(Javascript)側のテストツールだぞ。
XSSとかのテストに便利
（でも、ルール作るのが面倒やな。）
一つ一つのモジュールの出力をテストするにはPHPUnitとかかな。
790:nobodyさん
07/11/28 21:02:03
simpleTest使ってる奴はいねーの？
791:nobodyさん
07/11/29 10:22:46
>>786
Rubyの未来が心配になってきた…
792:nobodyさん
07/11/29 12:25:20
>>786
Googleは技術と戦略を軸に規模を拡大してきた。ただ、それが強みでも弱みでもある。楽天はオペレーションを加えた3つをしっかりとやってきた
何様だ？
楽天とgoogleなんて比べることすらおこがましいだろ
ruby魂売りすぎワロタ
793:nobodyさん
07/11/29 13:40:05
楽天って何のためにRuby採用したん？ Rubyって速いん？
794:nobodyさん
07/11/29 13:55:53
お互いに相手を利用してやろうって魂胆な気がする
795:nobodyさん
07/11/29 15:45:34
>>794
まさにそんな感じだ
おたがい腹の底では相手を全く尊敬してなさそう
796:nobodyさん
07/11/29 15:46:06
>>794
こけても
「まぁ、楽天(Ruby)だしな。」
と思われるので安心です。
797:nobodyさん
07/11/29 16:09:45 5C/J/t4q
>>794
Railsがもてはやされてる頃に、楽天が採用するって言い出したんだよな。
まぁ、どっちもどっちだ。
798:733
07/11/29 18:36:58
RailsもどきPHP自作FWの完成度が高まるにつれRailsどうでもよくなってきた。
でも一つの答えをくれたRailsに感謝。
楽天くらい開発スタッフかかえてるんなら自分たちでFW作って社内標準にすればいいのにな。
799:nobodyさん
07/11/29 18:39:18
自作君まだいたんだ
800:733
07/11/29 19:03:17
ごむぇん、にぃちゃん・・・
801:nobodyさん
07/11/29 20:34:40
作ってしまえば自作もいいぞ。全部自分好みにできる。
802:nobodyさん
07/11/29 21:40:55
オープンソースのフレームワークだって
全部自分好みにできるがな。
803:733
07/11/29 22:21:45
自作っていっても実質railsのパクリンだしね。
804:nobodyさん
07/11/29 23:44:43
自作とかみると、また嘘言ってるよと思う。
単に俺がしょぼいんだろうなあ…。
805:nobodyさん
07/11/30 08:57:17
世間一般に対するPRだな。世間と言っても、ウェブ開発の動向に興味を持ってる人の世間だけど。
楽天は安くて品揃え良くすれば、Ruby使おうがJava使おうがどうでもいいよ。と普通の世間の人は思ってる。
806:nobodyさん
07/11/30 10:44:14 bY6T+Roz
楽天はショップの管理画面をなんとかしたほうがいい
807:nobodyさん
07/11/30 12:19:43
google＝Java yahoo＝php 楽天＝Ruby
Rubyは良い言語だよね？
808:nobodyさん
07/11/30 12:28:20
楽天はrubyと組んでも損することはないが
rubyは楽天と組むとイメージダウンが著しいな
809:nobodyさん
07/11/30 13:36:29
つかGoogle=Javaってｗ
810:nobodyさん
07/11/30 14:15:18
google = pythonってイメージのがつよい。
811:nobodyさん
07/11/30 15:38:10
あれ、Googleって、java利用し始めたんじゃなかったっけ？
812:nobodyさん
07/11/30 15:40:46
前から使ってるとこには使ってるでしょ。
楽天だってjavaもphpも使ってるって言ってるし。
813:nobodyさん
07/11/30 17:13:05
GoogleはサーバサイドではJavaとC++が主流で、Pythonは管理ツールとか。
814:nobodyさん
07/11/30 17:24:40
大きな会社が一つの言語しか使わないなんて面白いことはしないと思いますよ
815:nobodyさん
07/11/30 17:40:31
ほんとこのスレってすれ違いな話しで埋まるよね
PHPでフレームワーク使ってる奴はレアな存在ってことを象徴してるよな
URLﾘﾝｸ(www.phppro.jp)
816:nobodyさん
07/11/30 18:53:18
>>815
それぞれ個別のFWスレがあるんで
実際に使ってる人達は基本的にそっちでやっている
このスレも前スレくらいまではもう少しまともだった
今はもう煽る奴と煽られる奴しかいない
817:nobodyさん
07/11/30 19:00:15
だから個別スレに分けるなって言ったのに・・・
818:nobodyさん
07/11/30 20:36:44
そろそろJavaを始めようと思います
PHPの難しさを100としたら
Javaの難しさはどのくらいですか？
ちなみにPHPは5でオブジェクト指向で書いてます
819:nobodyさん
07/11/30 20:50:41
単に言語として覚えるだけならそんな苦労はないと思う。
習得時間を要するフレームワーク覚えたり、Tomcatの設定とか
Javaでウェブアプリを作る上で付随することを覚えるのが辛いかもね。
820:nobodyさん
07/11/30 22:21:47
>>818
オブジェクト指向でかけるならそんな難しくないでしょ。
JAVAでもC++でも…。
俺、未だにオブジェクト指向を理解できてない…orz
821:nobodyさん
07/11/30 22:26:35
やってみればいいじゃない。
822:nobodyさん
07/11/30 22:36:21
>>820
やってみりゃいいよ。
俺はCからJavaに移る時に、3ヶ月目に これがクラスの力か！って閃いた。
初めて自転車に乗る時みたいなもんだ。
823:nobodyさん
07/12/01 00:09:25
俺はオブジェクト指向は難しくないけど、フレームワークがダメ。
824:nobodyさん
07/12/01 09:52:25
>>818
今まで変数の「型」について意識していなかったら結構ひっかかるかも？
それ以外はそんなに苦労しないんじゃないかな、と思う。
825:nobodyさん
07/12/01 10:51:28 sHVEWDE6
JAVAからはじめた俺はSETTERやGETTERがないと気持ち悪くて・・・
826:nobodyさん
07/12/01 10:58:52
仕事や勉強は別として、JavaやC/C++で作りたいものがある人は尊敬するわｗ
827:鍔莊 ◆SrChNIpw0A
07/12/01 11:20:34
test
828:nobodyさん
07/12/01 13:08:12
>>825
俺もだ。ナンセンスと言われようとも、そこはゆずれない。
829:nobodyさん
07/12/01 13:22:32
Pythonはsetter,getterなんて自動で作成しますけどｗ
昭和のかおりのする言語乙
830:nobodyさん
07/12/01 13:57:51
eclipseでやってりゃ自動生成あるからいいんだけどね＞Java
PHPは・・・Zend Studioおねがいしまつ。
831:nobodyさん
07/12/01 15:08:06
作りゃいいじゃん。
つか、作り方どっかに転がってなかったか？
832:nobodyさん
07/12/01 18:28:33
作れば・・とか言ってたらキリねーじゃんｗｗ
833:nobodyさん
07/12/01 21:18:44
>>829
ダウト
・・・いやほんとだったら教えて
834:nobodyさん
07/12/01 21:18:47
いや、だから、対応されるまでここでグチるより、作り方乗ってるサイトあるんだから見て作れるだろって話。
それこそキリないだろ。
835:nobodyさん
07/12/01 21:43:32 sHVEWDE6
PDTでつけてくれればいいんだけどな。SETTERとGETTERの生成。
836:ほれ
07/12/02 00:38:16
URLﾘﾝｸ(codezine.jp)
837:nobodyさん
07/12/02 05:30:09
ちょいすれ違いかも知れませんが
皆さんphpでDIコンテナって使う機会ありますか？
便利そうだなーと思うものの実際使ったことがないので効果のほどがわかりません
どうでしょうか
838:nobodyさん
07/12/02 07:23:30
>>837
あれはJavaのような融通の利かない言語のためにあるもの。
スクリプト言語にはまず必要ない。
config.php:
<?php $class = 'Foo'; ?>
main.php:
<?php $obj = new $class(); ?>
でたいてい間に合う。
ああAOPがあったか。AOPがやりたいなら悪くないかもしれんが、
スクリプト言語ならAOPも簡単にできそうだしなあ。やっぱいらんと思う。
839:nobodyさん
07/12/02 12:15:27
Mapleとかまったく無意味と言うか、センスのないフレームワークだったよな。
840:nobodyさん
07/12/02 12:26:50
とりあえず、復帰されたそうだから、俺は応援する。
841:nobodyさん
07/12/02 12:45:42
>>838
ってか、それMockとか作るたびにソース書き直してそれやってるの？
DIコンテナはやっぱりテストする際に、実装しているクラスとMockを簡単に切り替える点にあるといえる
インスタンスの管理だけがDIの利点ではないだろう。
もし、それだけなら単なるFactoryつくればおk
AOPについても同様で、既に作成済みのクラスや機能について
処理を追加したいと考えた際にAOPが無くちゃ何も出来ない。
誰かがソースを直して待つしかないなら、AOPで書き換えるようにする。
もしかして、ソース管理は自分一人でやってないよな？
842:nobodyさん
07/12/02 13:45:47
>>841
>ってか、それMockとか作るたびにソース書き直してそれやってるの？
そうだよ。変更箇所だけを集めたファイル(config.php)を作って、必要があれば都度書き換えてる。
DIコンテナも設定ファイルを書き換えるよね。そのXMLファイルがPHPファイルになっただけ。本質的な違いはない。
>DIコンテナはやっぱりテストする際に、実装しているクラスとMockを簡単に切り替える点にあるといえる
>
>インスタンスの管理だけがDIの利点ではないだろう。
>もし、それだけなら単なるFactoryつくればおk
「実装しているクラスとMockを簡単に切り替える」のは「インスタンスの管理」だと思うんだが違うのかね。
ついでにいうと>>838のコードは「実装しているクラスとMockを簡単に切り替え」ている例だと思うけど。何が不満なのかしら。
>AOPについても同様で、既に作成済みのクラスや機能について
>処理を追加したいと考えた際にAOPが無くちゃ何も出来ない。
>誰かがソースを直して待つしかないなら、AOPで書き換えるようにする。
それはJavaにそういう機能がないだけだよね。クラスの定義自体を動的に行うスクリプト言語にそんなこといわれてもなあ。
>もしかして、ソース管理は自分一人でやってないよな？
人数は関係ないんじゃない？Javaではソース管理が一人だとDIコンテナやAOP使う利点がなくなるの？
843:nobodyさん
07/12/02 15:18:44
あーMaple復活したんだ
844:nobodyさん
07/12/02 17:07:56
や、Mapleというより、今のところはkunitさんが復帰しただけかな。
個人的にはHawkさんこそ復帰して欲しい・・・。
845:nobodyさん
07/12/02 18:01:06
Mapleひきついで「あれ…俺たいしてプログラミング好きじゃないじゃん」
って気づいちゃった人だったけ？
846:nobodyさん
07/12/02 19:03:29
>>842
横レスすまんけど
DIつう仕組みがすでにあるのに俺俺ファクトリーみたいなのを使う理由って何だ？
煽りじゃなくて単純な疑問。答えてくれるとうれしい
847:nobodyさん
07/12/02 20:19:53
>>846
必要ないから。大げさだから。学習コストがかかるから。
俺俺ファクトリーで済むのにわざわざDIを使う理由は何だ？
Javaは融通がきかないからDIコンテナを使うのはわかる。
でも何でも実行時に行うスクリプト言語でわざわざ手間掛けてDIコンテナを使う理由はあるのか？
設定ファイル(config.php)：
<?php $klass = 'Foo'; ?>
main.php:
<?php require_once('config.php'); $obj = new $klass(); ?>
これですむような言語にDIなんて必要ないだろ。
848:844
07/12/02 21:17:48
>>845
お前Hawkさんとこに糞なコメント残したtestと同じタイプか？
何かしらプライベートであったからあーいう結末になったんだろ？
俺はあの人のサイトには随分世話になったんだ。
そういう言い方すんな、日本のPHP界にとっても有益な人だっんだ。
849:nobodyさん
07/12/02 21:27:44
本人乙
これでいいかな？
850:nobodyさん
07/12/02 22:03:43
高度に発達したFW信者はネットストーカーと区別がつかない
851:nobodyさん
07/12/02 22:21:46
>>848
糞なコメントって何だ？
事情は知らんが印象に残ってただけで中傷する意図はない
プライベートどうこうじゃなくて個人の資質の問題だろう
気づいたこと自体は気づかないままよりいいんじゃね
852:nobodyさん
07/12/03 00:08:04
>>841はDI厨。
>>846は訓練されたDI厨。
853:nobodyさん
07/12/03 01:09:56
何故にseasaaは叩かれないのだ。
854:nobodyさん
07/12/03 01:37:18
>>847
俺俺ファクトリーもそうだけど、ソースの修正量が増えたときに
インスタンス管理なんかを誰が管理しなくちゃ行けない場面が沢山あるんだよ。
少人数でソースの管理を行っているなら、コミットログとかコミュニケーションの範疇で
なんとかなるけど、規模が大きくなってくるとそれが大変になってくるんだ。
確かに俺俺ファクトリーでも十分使えるけど
>>847 の書いたようなコードが、実際に動く部分に混入するとそれこそ苦労倍増なんだよ。
だから、みんなでコンテナに登録してテストとかの際に切り替えは
コンテナからやっちゃいましょうね。っていう仕組みがDIで簡単にできる。
また、AOPについては前にも書いたけど、誰かがソースを修正しているときに
そのソースの修正を待たずに、処理を追加できる利点があるんだ。
ソースの完了を待って、自分のコードを書くのじゃ遅いから、
あらかじめインタフェースとかを切っておいて決まり事をつける事で
誰かに待たされる事なくプログラムを進める事ができるんだ。
って、長文すまん
855:nobodyさん
07/12/03 01:43:48
俺俺ファクトリーかDIかっていうのは結局のところ程度問題なわけか？
コンパクトで少人数なら俺俺、でかくて大人数ならDI、とかそういう感じ？
856:nobodyさん
07/12/03 03:11:05
>>854
>少人数でソースの管理を行っているなら、コミットログとかコミュニケーションの範疇で
>なんとかなるけど、規模が大きくなってくるとそれが大変になってくるんだ。
>確かに俺俺ファクトリーでも十分使えるけど
>>>847 の書いたようなコードが、実際に動く部分に混入するとそれこそ苦労倍増なんだよ。
おまえが何を問題にしているのかを明確にしてほしいんだけど、「（インスタンス管理のための）コードが、実際に動く部分に混入するとそれこそ苦労倍増」になることが問題ということでOK？
この前提が正しいとしたら、解答は「混入させない」。混入してたらそれはバグだから修正する。それだけ。
でもこれってJavaでも一緒だよね。Javaだと混入させない魔法でもあるの？
>だから、みんなでコンテナに登録してテストとかの際に切り替えは
>コンテナからやっちゃいましょうね。っていう仕組みがDIで簡単にできる。
だからそんなことはDIじゃなくても十分できるの。特にスクリプト言語なら。
>また、AOPについては前にも書いたけど、誰かがソースを修正しているときに
>そのソースの修正を待たずに、処理を追加できる利点があるんだ。
違うだろ。AOPの利点は次の2つ。
* 既存のクラスに手を加えることなく処理を追加できること
* クラス階層を横断して機能を追加できること
>ソースの完了を待って、自分のコードを書くのじゃ遅いから、
>あらかじめインタフェースとかを切っておいて決まり事をつける事で
>誰かに待たされる事なくプログラムを進める事ができるんだ。
それはAOP関係なくて、mockとかdriverとかstubとかいうものでやること。AOPである必要はない。
857:nobodyさん
07/12/03 03:56:12
白熱だなあ
858:nobodyさん
07/12/03 10:25:24 aJcrBH5W
AOPとかDIとかよくわかってない俺
859:nobodyさん
07/12/03 11:07:06
AOPとかDIとか全くわかってない俺も来ましたよ
860:nobodyさん
07/12/03 11:18:21
誰か忘れたけど、Perl on Railsを作ってるみたいだね。
って完全にスレ違いだな。ｽﾏｿ
861:nobodyさん
07/12/03 11:31:44
>>860 どの言語でもパクれるんですね。 んならPHPでいいや。
【総合】PHPフレームワークを語るスレ8
ｽﾚﾘﾝｸ(php板)l50
862:nobodyさん
07/12/03 18:20:40
URLﾘﾝｸ(slashdot.jp)
MD5脂肪でPHP脂肪ｗｗｗｗ
863:nobodyさん
07/12/03 18:35:44
>>862は釣りですか
864:nobodyさん
07/12/03 21:09:02
MD5脂肪→PHPはセッションでMD5値を使っている→三段論法でPHP脂肪ｗｗｗ
865:nobodyさん
07/12/03 22:25:35
>>864も釣りですか
866:nobodyさん
07/12/04 00:23:04
Javaで有効だったからPHPでも有効だと思ってるやついるね。
きっとDIとAOPがはやってるからという理由で勉強したJavaプログラマー、社会人3年目くらいか。
867:nobodyさん
07/12/04 00:43:22
個人的には人が書いた俺俺ファクトリーをいじるの(っていうかコード見るの)はやだなあ
使える場面では使ってもいいとおもうよ>DI
少なくとも毛嫌いするようなもんでもないと思う
868:nobodyさん
07/12/04 00:47:26
そんなに駄目かな？ＤＩ。
869:nobodyさん
07/12/04 00:48:51
静的型付け言語であるJavaと
PHPを比べてる時点でナンセンスだと思うけどね
870:nobodyさん
07/12/04 01:08:03
>>867
人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。
>少なくとも毛嫌いするようなもんでもないと思う
嫌ってるんじゃなくて、DIコンテナを使ってうれしい場面がPHPではないってことだろ。好き嫌いの話じゃない。
そんなにいうなら、どう嬉しいのかをちゃんと語ればいいじゃん。ちゃんと説得力を持って。
説得力のある理由がでてきてないから必要ないといわれるわけで。
871:nobodyさん
07/12/04 01:23:40
>>869
スクリプト言語にDIを勧めるほうがナンセンス
872:nobodyさん
07/12/04 01:31:29
DIとMockとAOPの違いを簡潔に教えて頂戴＞えろい方
俺の低レベルな理解力では次のように理解
DI：クラスを置き換えできる。
AOP：メソッドを追加したり置き換えできる。
Mock：DIと同じ？（DIをテスト用途で使うことに特化した呼び名？）
あとmixinってのもあるよね。
mixin＝AOP？
873:nobodyさん
07/12/04 10:29:36
>>872
AOPは既存処理の前後に共通化された処理を挿入する。（前後とは限らない？）
mix-inは、共通で使う処理を関数化しておいて、それを任意のクラスのメソッドとして使えるようにする。
とか俺も半端な知識で言っている。
てかスレ違い。この辺の議論やると終わらないし。
874:nobodyさん
07/12/04 12:15:47
phpで使えるdiコンテナてあるのな
scarletとか手軽そうだね
875:nobodyさん
07/12/04 12:38:33
>>870
>人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。
少なくとも同じじゃないだろ
俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ
>>870自身がどんな場合でもファクトリパターンで対応して
DIなんていらねーって言うんならもう何も言うことないけど
876:nobodyさん
07/12/04 16:47:36
>>875
>俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ
コードって、どれを指してる？
例えば>>847の例だと設定ファイルとメインファイルの両方ともPHPのコードなんだけど、どっちのコードの見通しが悪くなると思ってる？
>DIなんていらねーって言うんならもう何も言うことないけど
DIの概念自体を否定してるんじゃなくて、何でも動的なスクリプト言語ならDIコンテナをわざわざ導入する必要がないといってるだけ。
DIでやろうとしていることは、スクリプト言語なら言語仕様の範囲で簡単に実現できる。
PHPでもDIコンテナが役に立つ例をだれも出せてないじゃん。それを示せばみんな納得できるのに、出しもしないでDIマンセーされてもな。
877:nobodyさん
07/12/04 18:03:00
ほっとけよ。DI議論はもういい。
PHPでウェブプログラミングなんて、そもそも小規模なのばっかだし。
878:nobodyさん
07/12/04 18:30:24
まとめようか。
・DIの概念はPHPにおいても有効である。
・ただし、PHPでは>>847のように比較的簡単に実現できる。
・大掛かりな仕組みは必要ないじゃん。
JavaではDI必須。っていうのが当たり前になりつつあるようだけど
スクリプト言語では>>847のように比較的簡単にできてしまうことが、
静的型付き言語であるJavaでは一筋縄では実現できないから、Springとか
Seasarとかそういう大掛かりな仕組みが必要ってだけじゃない？
あと、Java的にはDI使うとクラス関係が疎結合になり
コンパイルが早くなるらしいね。
PHPの場合、大掛かりなDIを導入するメリットがJavaほどには無いように思う。
>>877そういうなよ。
なぜ、ぶった切ろうとする？
新しい話題提供できるならして欲しい。
DIについて話題になったのは、このスレでは初めてじゃない？
smarty必要か？PHPにフレームワークは必要か？とか
毎度毎度の定期ループしてる話題よりよほど良いと思うがな。
879:nobodyさん
07/12/04 19:29:14
自分が分からない話題が続くとイライラしちゃうんじゃないの？たぶん。
気にすることないよ。
880:nobodyさん
07/12/04 19:47:46
>>878
AOPについではどうだろうか。
JavaでDIのメリットの一つとして、AOPが簡単にできることが挙げられる。
というか、AOPなしだとDIのメリットは半減する。
・PHPでもAOPは有効か？（どんなときに？）
・PHPではAOPも簡単に実現できるか？（YESなら大掛かりな仕組みはいらない）
881:877
07/12/04 20:39:47
いや俺はDIいらないでおk。スクリプト言語にはナンセンスで。
てかjavaでもいいや。xmlに書くとかもうウンザリ。
コード読んだ方がどこで何やってるかわかりやすいわ。
他人の俺俺ファクトリーでもスキルある奴が作ってればそれでいい。
だいたいソース読んで困るのは、ファクトリとかそんな知識すらないバカのだし。
882:nobodyさん
07/12/05 01:58:35
DIについて俺の経験を書いてもいい？
以前開発していたちょっと中規模なプロジェクトがあったんだけど、
そのプロジェクトはDIコンテナのような仕組みが無くて、
>>847の書いたようなファクトリモドキを書いて、開発してたんだよ。
で、プロジェクトも終盤になってよし結合テストしよう！ってなったときに、
みんながcommon.phpみたいな必ず読み込まれるようなファイルに
$hoge = 'MyClass'
みたいな記述をして、どこからrequireされたか分からない、autoloadされたクラス内で
$obj = new $hoge($params)
と書かれてたんだわ。
それ自体は別に共通化されたファイル内に書かれていたから良かったんだけど、ときどきデバッグ用に
$hoge = 'OtherClass'
とかって書いちゃってるコードが混入して、結合テストがすごく大変だったトラウマがある。
あと、依存関係が全然整理されてなくて
public function __construct($str){
$this->hoge = new $str;
}
なんて記述があったときには、何をnewできるのか、何が newされる対象なのかがわからなくて、保守のときに大変だったトラ ウマがある。（ドキュメントがあまり書かれてなかったんだよね...)
それがあってから、俺が担当するプロジェクトはDIを使うようにしてる。
どこで生成されるべきか、どこで使うか、どうやって切り替えるかを明確にするためにDI使ってる。
設定ファイルの管理は面倒だけど、テストがその分、楽になったかな。
DIのメリットはこんな感じだった。
スクリプト言語でも十分使えると思う。管理という面においては。
883:nobodyさん
07/12/05 02:04:50
URLﾘﾝｸ(japan.zdnet.com)
Apache 2.0系、2.2系にクロスサイトスクリプティングの脆弱性
Apache脂肪でPHPまたもや脂肪ｗｗｗ
884:nobodyさん
07/12/05 02:15:00
>>883
先生！これはPHPだけの問題なのですか？
885:nobodyさん
07/12/05 08:48:32
>>884
そういうことにしといてやれ
もしくはスルーで
886:nobodyさん
07/12/05 09:18:00
>>882
>ときどきデバッグ用に
>$hoge = 'OtherClass'
>とかって書いちゃってるコードが混入して、結合テストがすごく大変だったトラウマがある。
これはデバッグ用のコードが本番用コードに紛れ込んでいたという話だよね？DI関係なくね？
DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。
>あと、依存関係が全然整理されてなくて
依存関係って、例えばどんなの？イメージがわからん。具体例で詳しく。
>何をnewできるのか、何が newされる対象なのかがわからなくて、保守のときに大変だったトラ ウマがある。
これ、DIコンテナで解消できるの？
Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。
これは言語の仕様によるものであって、DIを導入したからといって変わることはないはずだけど。
>（ドキュメントがあまり書かれてなかったんだよね...)
逆にいえば、ドキュメントを書けば済む話？
887:nobodyさん
07/12/05 10:42:51
>>886
>DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。
いや、そういう意味ではなく、デバッグコードが混在してしまったけど、それを探すのに非常に手間がかかるってことをいいたい。
スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない
だからコンテナをファクトリみたいに使って記述を統一した。
ここに、設定ファイル云々は関係ない
>これ、DIコンテナで解消できるの？
Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。
これこそがDI導入によるメリットだと思うが？必要とされるべきオブジェクトはコンテナによって注入される事で、依存関係を解決できるでしょ。
だからへたにnewするんじゃなくて、newするものをコンテナに置く。
>逆にいえば、ドキュメントを書けば済む話？
ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。
でも依存関係とかってドキュメントしにくい部品でもある
888:nobodyさん
07/12/05 11:58:35
>>886
>スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない
>だからコンテナをファクトリみたいに使って記述を統一した。
>ここに、設定ファイル云々は関係ない
いやだからさ、JavaでApplication.javaとconfig.xmlがあって、同じことをPHPでApplication.phpとconfig.phpにするとしよう。
デバッグコードはApplication.{java,php}に書いたの？それで分からなくなったというなら、それはDIも何も関係ないじゃん？どう関係あるの？
デバッグコードをconfig.{java,php}に書いて分からなくなったとしたなら、いくらなんでもセンスなさすぎだろ。config.phpで分からなくなるやつがconfig.xmlにしたところで解決できるわけない。
>これこそがDI導入によるメリットだと思うが？必要とされるべきオブジェクトはコンテナによって注入される事で、依存関係を解決できるでしょ。
>だからへたにnewするんじゃなくて、newするものをコンテナに置く。
これも分からん。まず依存関係が何かを具体例で説明してくれ。
それと、newするものをXMLファイルに書くのと、同じことをPHPファイルに書くことと、どう違うのかちゃんと説明してくれ。
>ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。
>でも依存関係とかってドキュメントしにくい部品でもある
だから何をもって依存関係といってるの
889:nobodyさん
07/12/05 12:17:17
ごめん、>>886じゃなくて>>887でした。
890:nobodyさん
07/12/05 12:21:46
>>887
Application.javaとconfig.xmlはこんなのね。
--- Application.java ---
S2Container container = S2ContainerFactory.create("config.xml");
InterfaceX obj = (InterfaceX)container.getComponent(ClassX.class);
--- config.xml ---
<component class="ClassX">
<initMethod name="initialize">
<arg>"foo"</arg>
<arg>123</arg>
</initMethod>
</component>
Application.phpとconfig.phpならこんな感じ。
--- Application.php ---
require_once("congif.php");
$obj = create_ClassX();
--- config.php ---
function create_ClassX() {
$obj = new ClassX();
$obj->initialize("foo", 123);
return $obj;
}
これらになんか違いがあるのか？
config.phpなら混乱するのがconfig.xmlでは混乱しないという理由を示してくれ。
891:887じゃないけど
07/12/05 12:49:30
なんかそのコード見せられると、configファイルはさすがにXMLに
してもらいたいと感じてしまう。
もっと規模が大きくなってから大々的な移行しなきゃならなくなって
設定ファイルを再利用する場合とか、XSLT等で簡単＆きれいに移行
できるし。
で、もしDIの設定にXML使うとすると、DIコンテナがその辺りのこと
を面倒見てくれるんだったら、それだけでも利用価値ありそう。
892:nobodyさん
07/12/05 12:50:34
congif見てザンギエフ思い出した俺ガイル
893:nobodyさん
07/12/05 13:36:32
やっぱりXMLは醜悪だな。設定ファイルはS式にするべきだ。
894:nobodyさん
07/12/05 13:52:03
>>891
利点ってそれだけ？
Java使ってる他のやつに聞きたいんだけど、設定ファイルをXSLT使って移行するなんてこと本当にするの？そんなプロジェクト今まで見たことも聞いたこともない。
891はほんとにそれをしたことあるの？あるかもしれないという妄想を語っても仕方なくね？
それにおまえのconfig.xmlは手作業での移行ができないほど巨大なのか？おれはせいぜい50行いかない程度なんだけど。
数十行の移行をXSLTで自動化するためだけに、わざわざDIコンテナを勉強して導入するコストは払えん。しかもそんな場面が将来あるかどうかも分からないのに。
895:nobodyさん
07/12/05 14:03:29
>設定ファイルをXSLT使って移行するなんてこと本当にするの
ないないw
ありもしないことを想定して無駄に作業増やすのがJava厨。
strutsのときも、フォワードのパスとかバリデータとか全部XML。
こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・
っていったらビルドのコストがとわけのわからないことを言う。
Java厨って変更の可能性のあるところは全部XMLに追い出した方が
保守性が高いという妄想に取り憑かれすぎ。
XMLに追い出すとソースと2重管理になってウザイって。
DBの設定とかローカライズのメッセージとか、そういうのだけでいいよ。
クラスの名前とかそんなもん追い出すとろくなことにならない。
896:nobodyさん
07/12/05 14:32:00
まあCやらJavaやらコンパイル言語使うと、ソースファイルの中には
設定値を書きたくないという気持ちは理解できる。
897:895
07/12/05 14:35:03
>>896
クラス名は設定値じゃないからなー
言語に依存してる物はソースに書く方が俺は良いと思う。
DIとか使わなくてもまともに動いて保守性の高いプログラムは書ける。
だったら使わない方法で俺は行く。
898:nobodyさん
07/12/05 14:39:05
ファクトリー厨の方々、必死すぎだろ
DI否定しないと気がすまんのな
899:nobodyさん
07/12/05 15:13:55
DI否定する気は無いがPHPで使う気にはなれない
900:nobodyさん
07/12/05 15:33:26
>>895
>strutsのときも、フォワードのパスとかバリデータとか全部XML。
>こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・
禿同
XMLに外だししなくてもいいものまで外だししないといけないのがアホらしい。
入力→確認→登録だけの簡単なページ遷移もXMLに書くのが面倒くさくて仕方なかった。
遷移先が変更になることなんかないんだって、簡単なアプリなら。
面倒を強制するな。
901:nobodyさん
07/12/05 15:36:14
>>894-895
俺の場合はPHPとは全く関係ないが、すでに出来上がってるシステムの
スケーラビリティ向上＋UIの一新を目的に大部分を書き直したことある
けど、そのときに設定ファイルの変更点はかなり少なかったからXSLT
使ったよ。
別に設定ファイルがデカイからではなく、そのシステムをデプロイして
使っている人が多かったから一挙に対応するために移行用のXSLT用意し
たらずいぶんあっさり終わった。
902:nobodyさん
07/12/05 15:42:51
>>898
891=887乙
903:nobodyさん
07/12/05 16:40:47
PHP3年ぶりぐらいに使おうと思って色々調べて、最近はPHPもフレームワークかと思いつつ
どれ使おうかと探したが、まあ一応本家だしZend試してみようかとサイトいったんだが
どうにもつながんねえ。
Zendframeworkって今落とせるのか？
URLﾘﾝｸ(framework.zend.com)
ここ自体応答無しなんだけど。
904:nobodyさん
07/12/05 17:01:28
>>903
昨日はつながってたんだが、
つながらんね
905:nobodyさん
07/12/05 17:09:29
URLﾘﾝｸ(www.zend.com)
こっからZend Studioの評価版落としてインスコ
インスコ先のbin\ZendFramework\libraryにFrameworkが入ってるお
906:nobodyさん
07/12/05 17:30:30
3年ぶりのたまたまが偶然鯖落ちかなんかと重なったのか・・・
>>905
たまたまっぽいんで復旧するまでまつことにするわ。
余計なのインスコしてレジストリ汚したくないし。
でも情報thx
907:nobodyさん
07/12/05 18:44:23
DIContainerの利点は、クラス名を変えれる事ではなくて、
依存関係の注入やインスタンス管理をまとめてコンテナがやってくれる事じゃないの？
つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、
この場で作ったCのオブジェクトににセットして…
とかみたいなコードをいちいち書かなくて済むようになる事こそがメリットだと思う。
908:907
07/12/05 18:49:05
2文目、書いたり消したりしてたら色々変になっちまった。スルーしてくれ。
909:nobodyさん
07/12/05 18:50:44
>>907
これもDIコンテナなしで十分実現できるんだろうけど、せっかくだしもうちょっと話を聞かせてもらおうか。
>つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、
>この場で作ったCのオブジェクトににセットして…
ここらへんを詳しく。DIコンテナのメリットが分かるような具体例つきで。
910:nobodyさん
07/12/05 20:13:07
>>907じゃないけど、
DIコンテナなしでも実現できるから
DIコンテナいらないってのはなんかちょっと違うと思う
Javaは機能毎にコンポーネントを細かく切りまくって
ひとつひとつは小さい機能でたくさんのクラスを用意する傾向がある
（PHPをはじめとするスクリプト言語と比較してという意味で）
でそのたくさんのクラスをできるだけ疎結合にするために
ConstructorInjectionなりSetterInjectionなりで
外部からインスタンスを注入するようする、
それがDependency Injection（であってるよな、、）
そうした際に、ある機能（モジュール）を使いたいと思ったときにも
上に書いたようにクラスが細かく分かれているから
様々なインスタンスを注入しなければならなくなる、
AというモジュールはBの注入が必要でBはCとDが、DはEが・・・
とインスタンス間の依存性が複雑になっていった時に、
いちいちその注入のためのコードを毎回書き直して
コンパイルし直すような手間を減らすのが
DIコンテナの役割だと思うんだけど
>>907もおそらくこういうニュアンスだったと思うんだが
俺も別にスクリプト言語でDIコンテナとかいらないと思う
スクリプト言語だと比較的（Javaと比べて）多機能の大きなクラスを作るし
コンテナで管理しないと困るなあと思うほど
インスタンス間の依存関係が複雑になるケースがそんなにないから
そういう意味でPHPにDIコンテナは要らんってのは分かるけど
DIコンテナという仕組み自体が要らんとかだめだとか
それはまたちょっと違う問題じゃないのという気はする
911:nobodyさん
07/12/05 20:51:19
結局好みの問題もあるしなー
でもなんにせよJavaのやり方って普及しないよね。
Javaの崇高なる理論を元にした設計方針
→バカは理解できないから徹底は難しい
優秀なエンジニアの集団
→そのプロジェクトで一番効率的なやり方を自分たちで編み出してやる
912:nobodyさん
07/12/05 22:00:20
結局好み
913:nobodyさん
07/12/05 22:10:55
JAVAの山に幾度か登ったけど、全てリタイヤ… orz
914:nobodyさん
07/12/06 00:19:55
>>910
だから具体例で説明しろって。
依存関係というのが複雑な例を出して、そのXMLを書いてみせろ。
そしてそれがPHPコードで書くと複雑になるのが、DIコンテナだとすっきり書けるというのを実際に書いて示せ。
具体例を示さずにDIマンセーするのウゼエ
915:nobodyさん
07/12/06 00:31:56
>>910は別に
DIマンセー
と言ってるわけではないだろうが
なんでも噛み付くおまえもウゼエ
916:nobodyさん
07/12/06 00:38:46
PHPER仲違いでPHP脂肪ｗｗｗ
917:nobodyさん
07/12/06 00:41:48
何言っても具体例で説明しろとしか言えないんだろ
918:nobodyさん
07/12/06 01:18:29
DIコンテナ自体理解できないから具体例出して欲しいんだろうよ
919:nobodyさん
07/12/06 02:05:44
おまえらが具体例出せないことはよくわかった
920:nobodyさん
07/12/06 10:46:27
バイトがゴキブリ揚げてケンタッキー脂肪ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
URLﾘﾝｸ(news.livedoor.com)
921:nobodyさん
07/12/06 11:19:50
DIの具体例って前から説明されてね？
っていうか具体例だしても、挙げ足なら誰も書けないと思うんだけど。
922:nobodyさん
07/12/06 11:23:59
DIを理解できない頭の悪さを他人のせいにしてるだけだよ
一連の書き込み見てりゃわかるけど
923:nobodyさん
07/12/06 13:32:45
>>921
>DIの具体例って前から説明されてね？
どこに？
924:nobodyさん
07/12/06 13:35:42
>>923に、わかりやすく言えば、班長さんみたいなもんだ。
925:nobodyさん
07/12/06 13:42:24
>>921の文章が難解だと思うのは俺だけでしょうか？
926:nobodyさん
07/12/06 17:06:31
残り少ないレス可能数に、DI 話で盛り上がってるのでスルーされてそのまま
DAT落ちしそうですが、一昨日から試行錯誤しても駄目だったので冒険します。
PRADOのSqlMapについてなんですが
やりたいこと：
～略～->QueryForList( 'FooBar', array( '%aaaa%', '%bbb%') );
から、
SELECT * FROM table WHERE ( str Like '%aaaa%' OR str Like '%bbb%' )
に展開して結果を取得したい。（配列数は可変）
やった事：
SqlMap.xml に、
<statement id="FooBar" parameterClass="array">
SELECT * FROM site WHERE
<iterate open="(" close=")" conjunction=" OR ">
str Like #[]#
</iterate>
</statement>
を追記したのですが
Unable to find property '[]' in object 'false' for parameter map 'FooBar-InLineParameterMap'
と出てうまくいきません。
PRADOのSqlMap Manualには <iterate> について書かれていないし、参考にしたのが
URLﾘﾝｸ(trac.pradosoft.com)
だったりするのでまだ未実装なのか記述ミスなのかもわかりません。。。
どうやったらうまくいくのかヒントでも何でもいいので、お示しをお願いします。。。
927:nobodyさん
07/12/06 17:13:51
そんなの使わなければ、つまづく事も無いのにね。
928:nobodyさん
07/12/08 05:30:02
URLﾘﾝｸ(japan.zdnet.com)
OSX脂肪でPHP脂肪ｗｗｗ
929:nobodyさん
07/12/08 17:30:22
PHPやっててフォークやソケットやスレッドの知識が身に付きますか？
同じスクリプト言語でもPerlなら付きます
PHPしかしないのは技術者として自殺行為です
初心者こそ最初は他の言語をしましょうね
930:nobodyさん
07/12/09 01:24:32
PHPのことを知らないのなら
黙ってれば恥かかなくてすむのにねｗ
931:nobodyさん
07/12/09 05:26:30
PHP自体がフレームワーク
932:nobodyさん
07/12/09 05:32:16
まあフレームワークは制限だからな
933:nobodyさん
07/12/09 05:33:35
このスレを見ている人はこんなスレも見ています。(ver 0.20)
フケ・痒みがとまらないPart9 [身体・健康]
まだ止まらないのかよｗ
934:nobodyさん
07/12/09 07:36:41
もともとフレームワークのPHP使ってフレムーワーク作る人って恥ずかしくないのかなｗ
935:nobodyさん
07/12/09 07:44:51
そんな事言ったら、どの言語だってそうだろ。
ちなみにフレムーワークは作った事ないけど。
936:nobodyさん
07/12/09 12:05:37 v5bnJUO2
俺もそろそろフレームワークデビューしてみたい（っ´∀｀）っ
937:nobodyさん
07/12/09 12:20:44
PHPはフレームワークとしては貧弱だからな
１枚ぐらい皮を被せたくなるぞ
俺は薄い皮希望だがな
938:nobodyさん
07/12/09 13:22:15
より多くの案件をこなすのが目的なら
CakePHP
導入までの敷居が低い ＝ 設置できるレンタルサーバーが多くなる
難易度が低い ＝ 多くの技術者がすぐにプロジェクト参加できる
FWの程度が中規模 ＝ オリジナルなFWに変更しやすい
したがってCakePHPがダントツに流行ることは間違いない
939:nobodyさん
07/12/09 13:30:49
俺様分析おつかれさん
940:nobodyさん
07/12/09 13:36:11
RoRがどのレンタルサーバーでも標準装備されれば
RoRが爆発的に流行すると思うが
phpで出来ることをRoRを覚えてまでやる必要があるかどうか
phpの豊富なWEB用ライブラリを超えることはまず不可能だと思う
なぜならphpはWEBだけに特化した言語だから
941:nobodyさん
07/12/09 13:40:00
symfonyはFWにしては大掛かりすぎるのが難点
それゆえに自由度が利かない
案件に合わせてFWを選択するのが一番いいと思うが
CakePHPならどの案件でも使える可能性が高い
942:nobodyさん
07/12/09 13:42:29
PHPはフレームワークじゃなくて、ただのスクリプト言語だからｗ
943:nobodyさん
07/12/09 13:58:55
俺はcakeがどうだとかethnaがどうだとか言ってる奴が根絶するまで
PHP4ベースで書かれてるFWは今すぐ捨てろとここに書き続けるつもりだよ
944:nobodyさん
07/12/09 15:01:24
RoRを設計を参考にしたフレームワークが沢山出ている現状だと、
爆発的に流行することはないと思う。(CakePHPもそうだしね)
それにどう頑張ってもRubyは遅い。
945:nobodyさん
07/12/09 15:26:21
Ruby のブロックをPHPに移植してケロ
946:nobodyさん
07/12/09 15:47:26
せめてクロージャでもあればいいんだけどな
947:nobodyさん
07/12/09 16:40:22
ブロック付いて、配列が[]で書けて、配列とハッシュが区別されて、
型が全部オブジェクトになって、組込クラスが整理されて、
オープンクラスになって組込クラスも自由に書き換えられるようになったら
PHPで本気出す
948:nobodyさん
07/12/09 16:57:14
それPHPの意味なくね？
949:nobodyさん
07/12/09 18:14:30
糞言語でもそこそこ何でもできるので
一度覚えるとそこに安住してしまいがちなのがPHPの最大の欠点だな
950:nobodyさん
07/12/09 18:52:11
HTMLに埋め込めて、$_REQUESTと$_SESSIONがいつでも呼び出せる。これ以上望む物はないよ。
951:nobodyさん
07/12/09 19:05:19
PHPのセッション実装なんてヘッポコじゃないですか
952:nobodyさん
07/12/09 19:37:21
>>942
> PHPはフレームワークじゃなくて、ただのスクリプト言語だからｗ
Rubyははフレームワークじゃなくて、ただのスクリプト言語だからｗ
で？
953:nobodyさん
07/12/09 20:10:57
で？
954:nobodyさん
07/12/09 20:53:42
/ﾆＹﾆヽ
/（ ﾟ )( ﾟ ）ヽ
／::::⌒｀´⌒::::＼ でっていうｗｗｗｗｗｗｗｗ
| ,-）＿＿＿（-、|
| l |-┬-| l |
＼ `ー'´ ／
955:nobodyさん
07/12/09 21:04:50
釣りばっかだな
956:nobodyさん
07/12/09 21:26:06
>>943 同意
まあレンサバもPHPなんて動けばいいんだろって思ってるから
なかなかPHP5に全面移行できないってのはいいんだけど、
環境が選べる状況で開発している奴らでもPHP4を引きずったり
いつまでもEUC-JPで書いてみたりっていうのは正直吐き気がする。
携帯だからってソースもSJISで書くとか、もういい加減にしてくれ。
UTF-8通る携帯もたいがい増えてるっていうのをなんで敢えて
スルーかな。
なんか質の悪いやや古参PHPerが癌すぎる。
957:nobodyさん
07/12/09 21:33:46
>>56
UTF-8通らないケータイではSJISで書く
UTF-8通るケータイではSJISも通る
世の中のケータイがすべてUTF-8通るならまだしも、そうでないならSJISで書くのは合理的だと思うけど。
958:nobodyさん
07/12/09 21:40:40
SJISでソース書くやつはバカ
959:nobodyさん
07/12/09 22:03:27
内部（ソースコード含む）はすべてUTF-8で統一し、
入力と出力時にSJISなりに変換すれば良いだけの話だろ。
960:nobodyさん
07/12/09 22:09:00
>>958
いや、そうじゃない。
SJISでソースを書くにしてもoutputで、UTF->Shift-JISに正しく変換できない実装がバカ
そのあたりはやっとPHP6で改善される可能性もあるけど、iconvとかmb_*系の実装はどうなるんだとか
そもそもMS932系の実装はどうなるんだろうか、なんてのを正しく議論していないPHPの上の人らがバカ
あと、全然関係ないけど、javaに近づけとはいわないけど、言語実装を議論せずに矛盾ばかり生み出す言語実装を作ってる上のひとらがバカ
961:nobodyさん
07/12/09 22:17:02
つまり携帯のフロントもあるバックエンドをEUCで書くやつは問題なく馬鹿、てことでおｋ？
962:nobodyさん
07/12/09 22:40:08
>>960
それ（変換とか）よりもSJISの場合はダメ文字絡みがやっぱり一番大きいと思うんだ。
シングルバイト圏の作るライブラリとか。
大体文字コードの変換なんてかつては「必要悪」だったのが今やただのオーバヘッドや
不具合の温床だと思ってそれほど間違ってるかな。
要はWindowsさえ次のOSでごにょごにょやってSJIS(CP932？)捨ててくれれば、問題の
大部分はweb系に関してはほとんど片づきそうな気もする。
963:nobodyさん
07/12/09 23:28:47
結局PHP使う奴はバカでFA