トップページ⇒php
1001コメント310KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2007/12/11(火) 23:37:20ID:???
前スレ
http://pc11.2ch.net/test/read.cgi/php/1192604501/
0236nobodyさん2007/12/20(木) 02:00:32ID:???
namaspaceがサポートされるのはいつごろなんだろうか
5.3ではサポートされるんだよね？
0237nobodyさん2007/12/20(木) 03:56:57ID:???
>>235
切り捨て過ぎじゃね？
ページ遷移伴って破棄される齟齬を埋めるために、永続化関係が語り尽くされた上で今がある訳だしさ。

WOやらStrutsやらがそれぞれのポリシーで上手くやって来た上でRoRとか出て来てるの見ると、オブジェクト指向云々って話じゃなくなってる感じもするな。
如何にlazyに手軽にサブセットDSLやれるかっていう、LL系で実行効率無視したシロモノが好評な時代だし。
結局みんなMVCやりたいのでもOOPやりたいのでもなく、DRYやりたいだけなんじゃないかな。webアプリではなおさら顕著な点だと思う。
クラスを「メソッドとデータをまとめたもの」という切り口だけで扱ってる／しばしば扱わざるを得ない、という状況になると（それが頻繁すぎるんだけど）もうOOPもOOADやらも意味なくなっちまう。
ページ遷移モデルだと、カプセル化使い回しも意義を損ねるし。ポリモルとかPHP自体がそこまで動的に設計できるモンじゃねえし。

そもそも毎ページで色々newされる動きにOOPってマッチしてないかも。
純htmlからJavaScript経由でサーバにアクセスして、永続的オブジェクトにアクセスするサーバサイドスクリプトが走るって動きならまだ納得行くかも。
MVCとか言う前に、クライアント側の設計／サーバサイドの設計をどう見つめ直すかが勝負じゃねえのかな。
0238nobodyさん2007/12/20(木) 09:47:11ID:???
>>235
どうせ、お前のはオレオレOOだろｗ
0239nobodyさん2007/12/20(木) 13:50:29ID:???
ウェブアプリって、データの保存がRDBMS、出力先がHTML。この2つともまったくオブジェクト指向じゃないんだよな。だから、ウェブアプリ自体がオブジェクト指向と相性が悪い。
オブジェクト指向と相性良くしようと思えば、RDBMSじゃなくってOODBにするとか、HTMLを全部DOMで操作するとかにしないといけない。
0240nobodyさん2007/12/20(木) 14:31:22ID:???
そんなことない。
よっぽど複雑なスキーマならともかくテーブルの親子関係もhas_a,has_manyで表現できるし。
中の人はOOPと無縁なSQLで動いてはいるけど。
HTMLは単に整形テキスト出力と割り切るべし。
てかゲームとかもっと複雑なプログラムなんかと比べたら全然楽だってウェブなんか。
0241nobodyさん2007/12/20(木) 16:35:58ID:???
えええええええええええええええええええええええええ
0242nobodyさん2007/12/20(木) 16:52:19ID:???
ゲームもやってたけどゲームのが楽だった。
アルゴリズム考える必要皆無なのがWebのいいところではあるが。
何が怠いってWebはブラウザの挙動がマチマチだったりクライアントの状態がわからないからな。
ゲームなら全部こっちの思い通りにいけるし、OSとかで限定すれば環境も固定だし。
プログラムの深さって意味じゃゲームのが深いかもしれないが、
Webは神経使うんだよな、特にクリティカルなところだと。
ゲームとかちょっと変な動きしてもまあいいっかで済ませられたりするしｗ
ゲームのプレイ自体には金が絡まないしな。
Webだと課金関係とかクレジットとかショップとかだと金が絡むからそこでバグると大変な事になるんで神経使う。
0243nobodyさん2007/12/20(木) 17:03:46ID:???
Webはオンラインで公開するという明確な意義があるんで、動機づけに繋がるんだけど、
ゲームやソフトウェアの開発ってオフラインのイメージが強くてどうも関心が持てない。
誰かのためというよりは、自分のためにシコシコ組んでる感じ。どうでもいいけどさ。
0244nobodyさん2007/12/20(木) 17:46:49ID:???
>>239
> ウェブアプリって、データの保存がRDBMS、出力先がHTML。この2つともまったくオブジェクト指向じゃないんだよな。

出力先がオブジェクト指向なものってなに？

（CUIを含めた）ユーザーインターフェースを持たないプログラム？
0245nobodyさん2007/12/20(木) 17:49:57ID:???
>>239
> オブジェクト指向と相性良くしようと思えば、RDBMSじゃなくってOODBにするとか、HTMLを全部DOMで操作するとかにしないといけない。

うん。だから今のモダンなウェブアプリ開発では、
オブジェクト指向でデータを読み書きできるO/Rマッパーと
HTMLを作成してくれるオブジェクト指向ライブラリを使うのが当たり前。
0246nobodyさん2007/12/20(木) 18:57:15ID:???
> HTMLを作成してくれるオブジェクト指向ライブラリ
ってのがどういうものか今ひとつイメージできない俺。
当たり前、なのか？

まさか全部DOMでノードノードで組み立てるようなもんじゃ無かろうな。
XMLの悪夢再び？
0247nobodyさん2007/12/20(木) 18:59:50ID:???
O/Rは薄皮一枚かぶせて紐付けしてるだけでしょ
その利便性が評価されてるだけで
オブジェクト指向でデータ読み書きって意味不明

OODBって昔から言葉だけ一人歩きしてるしな
実用性あるOODB作るのが難しいとか聞くし

HTML生成も、直書きなテンプレートエンジンばかりだよな
一からDOM組み上げる物view設計って見た事無いぞ
0248nobodyさん2007/12/20(木) 19:07:21ID:???
被った
でもXML/XSLTも構造に対するテンプレートに過ぎないよな。
DOM中のイベントに対してもOO言語側のメソッドとブリッジするくらいじゃないと怪しいかも。
0249nobodyさん2007/12/20(木) 19:17:32ID:???
>>248
そのイベントのブリッジ？は全ての場面で気軽に使うのは現実的でない、ていうAjaxの教訓もあってだな。
一回マウスが「オブジェクト」の上をかすめるだけで何十Kmもパケットが行き来してApacheがアクセスログ
吐いてPHPのオブジェクトを一からnewしてDB接続を作成してって・・・どれだけリッチなんだｗ

UI全部JavaScriptもしくはFlashで作るような形になってしまえってことなのか。結局は
0250nobodyさん2007/12/20(木) 19:33:23ID:???
>>243
規模によるよ。プレステとかコンシューマー系で1年以上かかって作るゲームのがよっぽど大変。
そっちからウェブに来たけどはっきりって楽勝。ママゴトプログラミング。
0251nobodyさん2007/12/20(木) 19:34:03ID:???
webやMVCとOOPの相性悪いからOOPじゃないとか
OODBだとかDOMだとか、もうね、極論過ぎだろ
webプログラミングしたことないアホしかいないのかここは

最低限OOPの理解とFW使ってwebプログラムしてる奴か
これからしようとしてる奴くらいにしてくれよ
正直読むに耐えない
0252nobodyさん2007/12/20(木) 19:41:05ID:???
w
確かにUI層はJS/Flash(+flex|air類)/silverlightの進化に期待できそう。

別のアプローチだと、FastCGIやapache module酷使して画面遷移による切断を回避していく動きもあるな。そういう局面ではもっとOOとして意義ある実装が検討できそうだけどね。

でもどんどん複雑化するな。

結局当面の妥協点としては、フレームワークやO/Rマッパー、テンプレートエンジンを使ってOO関係ない世界に適用していく事になるんだろうなぁ。
0253nobodyさん2007/12/20(木) 19:43:28ID:???
PHPでのwebプログラミングしかしたことのない>>251みたいなやつは結構いると思うがな
そういえばあんまり書き込みないな。がんばってくれ>>251
0254nobodyさん2007/12/20(木) 19:44:36ID:???
>>251
極論しすぎなのとwebprogしたことないのがどう繋がるのかw
無理して何か言おうとしなくていい。
みんな極論通して突っ込みあって遊んでるだけだw
0255nobodyさん2007/12/20(木) 19:45:55ID:???
さっきから俺がもう一人二人いる感が拭えないスレだ
0256nobodyさん2007/12/20(木) 19:51:36ID:???
PHPスレだからPHPだけの奴は悪くないと思うけど、
他の言語環境渡り歩いた結果、貸鯖案件増えてPHPに落ち着いた奴も多いだろうしな
相互理解が進んで欲しいもんだ

PHPの適用範囲が絞られてるせいか、Javaだけの奴とかRubyだけの奴に比べるとこのスレの空気はマシな気もする。
0257nobodyさん2007/12/20(木) 19:54:59ID:???
>>250
コンシューマー系って時代によるだろうけど、俺俺FW作るところから始めてるような時代かしら
そういう視点から見るとPHP系のFWに不満ない？
そういう経緯の方が何使ってるか興味大。設計面や実行効率含めて面白い話が聞けそうな。
0258nobodyさん2007/12/20(木) 20:11:00ID:???
>>256
いや、環境問わずローカルで試しまくれる時代なんだから、言語はある程度触った方がいいだろ。
言語問わず、一つしか知らないってのはプログラマとして問題。
0259nobodyさん2007/12/20(木) 20:45:29ID:???
そろそろOO理解してない馬鹿の独り語りは終わりましたかね？
0260nobodyさん2007/12/20(木) 20:57:22ID:???
本当にOOでView作りたいなら、JavaScript もしくは Flash または Javaアプレットってのは
一つの見識だと思うがな。
PHPはXML（ｗ）でも吐いておけよ、てな感じか。

それをただHTML文字列を出力するライブラリをむりやりOOにしようとして苦しんでるのが
現状、っていう流れじゃないのか？ここ数レスは。
0261nobodyさん2007/12/20(木) 20:58:32ID:???
適材適所を知らない人なので放っておきましょう。
0262nobodyさん2007/12/20(木) 21:08:42ID:???
Flashww
アプレットwww

オブジェクト志向なんちゃらの前に、HTMLのタグ打ちからやり直したらどうよwww
0263nobodyさん2007/12/20(木) 21:15:47ID:???
flashを馬鹿にするやつは素人
0264nobodyさん2007/12/20(木) 21:19:07ID:???
FlashとXMLを並べて語る馬鹿に言われたくねーwww
その辺を判ってない事を馬鹿にしてるんだがw
しかもアプレットは単体で噴けるw　何年前の知識www
0265nobodyさん2007/12/20(木) 21:20:50ID:???
>>264
別にそんなこと語ってないけど
0266nobodyさん2007/12/20(木) 21:25:12ID:???
別人なら悪かったが、文脈読んでからレスしろよ
フラッシュのアクションエディッタでオブジェクト志向とかありえないんだから
0267nobodyさん2007/12/20(木) 21:26:02ID:???
似非OO信者は、
テンプレートを否定しているのか？ｗ

オブジェクト指向 = DOMで操作しないとだめとかアフォだろｗ
0268nobodyさん2007/12/20(木) 21:28:31ID:???
>>264
一つ勉強したいんだが、Flashはサーバからデータを取得するとき、どういう形式で取得するの？
Flashのオブジェクトで取得できれば一番いいんだろうが、それはサーバが限定されるだろうし。
0269nobodyさん2007/12/20(木) 21:33:41ID:???
>>268
スレ違いもほどほどに。普通に変数列にしてクエリで渡す。それ以上はFlash板へどうぞ
0270nobodyさん2007/12/20(木) 21:35:45ID:???
>>205の説明まんまな奴らが湧いて来たな
適材適所だというに
0271nobodyさん2007/12/20(木) 21:36:42ID:???
>>269 thx
つまり俺フォーマットか。それだけじゃ無かろうがなｗ
確かにスレ違いかも

PHPのViewの話だっけ。
ぶっちゃけテンプレートエンジンでいいんじゃね？ OOであろうが無かろうが
所詮 require の延長で、string取得してごにょごにょして echo もしくは eval なんだから
0272nobodyさん2007/12/20(木) 21:39:12ID:???
けど、ほんとにFWに固執してる人はリアルで居るよ。
FWを使うこと自体が目的化しちゃってるやつ。
02732502007/12/20(木) 21:48:54ID:???
>>257
もちろん俺俺フレームワークｗ
ライブラリは使いまくるけど、FWいらんかな。
でもRailsに触れてからは、これが一つのウェブプログラミングの答えだと思った。
symphonyとか使ってみようかな。
MVCとかOOPとかの議論もいいけど、一番大事なのは開発効率。
Javaの人ら見てると、どうだこれはすごい設計技術だろーみたいな
作り手の自己満足ばっかが先行してて開発効率にフォーカスしてない。
Railsはその辺はいい。
ウェブなんかほとんどオママゴトなんだから、これでええやん、みたいな。
0274nobodyさん2007/12/20(木) 21:51:01ID:???
FW以前にOOも一緒かも。
重くなるだけな部分までクラス化してnewしまくるコードに書き換える、オブジェクト指向してるつもりなだけの論外な奴
MVCって概念だけに溺れて自分で作りにくくしてる奴もいるし
0275nobodyさん2007/12/20(木) 21:55:14ID:???
>>273
基本的には同意だが、少し間違うとコピペでいいじゃんコピペが一番速いんだから
いらんことするなってなっちゃう人も多いんだろうなと想像する

何より社長（自分の雇い主）がそれを言い出したときすごく切なくなる
たしかにそれが一番いい局面もあるんだろうけど自分にはまだそのバランスがわからんし
02762502007/12/20(木) 22:22:47ID:???
>>275
いかに似たコードを2度書かないようにするかは永遠の課題。
最近、その辺はコードの自動生成ツールを作ることで回避してたり。
PHPはともかく、JavaやC++みたいに型あると、
型は違うけどコードのフローは同じようなのって、
クラス設計頑張ったり、テンプレート駆使したり、
上にあるDIとか使ったりするんだろうけど、
そうするとどうしても複雑になってくるよね。
何か問題起きたときソース追うのが大変。
そういうとこはコード自動生成ツール作って、そいつに重複コード吐かせちゃう。
コードのフローは素直なのにできる。デバッグも楽になれる。
重複コード書くべきでないってのは、同じコードが点在するのが問題じゃなく、
修正が一箇所で済まなくなるから。
自動生成ツールなら同じコードが散らばってても、直すのはツールだけで済む。
とか自分は思うわけですよ。
OOPで頑張るのもいいけど、こういう逃げ道もありとおもうけどな。
まぁコード自動生成を嫌がる人は多いんだけど。
0277nobodyさん2007/12/20(木) 22:43:32ID:???
コード生成ツールってメンテナ複数人にまたがると意思疎通しにくくなるのがなぁ。
ローカルでツール共有するのも手間だし
俺もサーバサイドでrubyにphp吐かせるとか狂った事やったけど、人とサーバ増やされるというので慌てて組み直したw

その辺railsって手際よくまとめてるよな
railsにPHP吐かせられないもんかなw

OOPやMVCしたいんじゃなく、一元化や効率化を徹底したいだけなんだよな、結局。
OOPやMVC、DIなんかに手法的価値がある局面はあるけど、OOPが目的になっちまうと沈む
0278nobodyさん2007/12/20(木) 23:11:11ID:???
コードの自動生成を認めるには多分条件があって、それは
生成されたコードをいじるなとｗ
それが出来るのなら、>>276もありかと思う

逆に、ただのソーステンプレートとしてコードジェネレータを使う
（いじること前提）なら、ポイントは生成されるソースの行数になりそう

結局railsよくできてるよなってなるんだけどｗ
02792502007/12/20(木) 23:17:16ID:???
>>277
結局人が増えると、各々やり方の差があるからね。
その辺は、フリーになって1人でやる道に逃げて解決w

OOPやるためにOOPやってる人っているよね。
Javaの現場での話だけど、O/RマッパーはあくまでDTOであって、
Modelじゃないって考えの人がいた。
DTOって結局はテーブルと同じ構造だからDBよりの産物で、
ModelでDB的都合は隠蔽すべきって考え。
Table -> DTO(運び屋) -> Model
なわけでDTOではテーブルのカラムのgetter/setter以外の実装は一切許されず。
でも、テーブルとModelの構造は、ほとんどの場合1対1になるわけで。
やることと言えば、ModelのコンストラクタにDTOを渡してModelのメンバに格納。
ModelにDTOと同じgetter/setterを作って中でDTOのgetter/setterを呼び出し。
そして、初めてModelに実装が書ける。
結局、同じ構造のクラス2回作って手間2倍、重さ2倍、メモリ浪費2倍にさせられただけ。
テーブルにカラムが変更したときテーブルが増えたときの作業に萎え萎え。
02802502007/12/20(木) 23:20:22ID:???
>>278
もちろんいじるのは禁止。自動生成ツールはリポジトリで管理。
さらにコミットしたときに自動的にサーバーで自動生成ツールが走る。
なんで勝手に上書きした糞野郎のコードは消えるw
0281nobodyさん2007/12/20(木) 23:58:14ID:???
>>280
それもう自動生成ツールじゃなくね？ライブラリと変わらんじゃないか
すでに生成されたものは面倒でも手動で再生成してマージさせるべきだとおもう
0282nobodyさん2007/12/21(金) 00:02:54ID:???
ウェブアプリにオブジェクト指向が要らないのは、RDBMSとHTMLが非オブジェクト指向だからっていうのはすでに言ったが、もう一つ根本的な理由がある。
それはオブジェクト指向にしないといけないような複雑な機能を持ったウェブアプリはほとんどない。
例えばgmailだったら、メールをクラスで表現した方がいい。というか、クラスにするしかない。
が、世の中のほとんどのウェブアプリはDBの結果を連想配列に入れて後はそれをHTMLの中に埋め込むだけ。
オブジェクト指向の出番はない。
0283nobodyさん2007/12/21(金) 00:07:25ID:???
>>282
お前の扱ってる案件がそのレベルなだけだろ。
0284nobodyさん2007/12/21(金) 00:10:53ID:???
gmailと同等の機能を持つウェブメールサービスが世の中にいくつあるか列挙してもらいたいもんだ。
02852502007/12/21(金) 00:16:54ID:???
>>281
自動生成ツールだけど2パターンあって、
1つは作ったのは手で絶対触らない＞これは出力されたコードはライブラリみたいなもんかもね
もう1つはコードのテンプレート自動作成＞Railsでモデルやテストクラスのひな形が自動でできるみたいな
俺が上で言ったのは前者ね。

>>282
ホントその程度で済む内容の開発ばっかなんだよね。
ビューにコード書くなってのは徹底すべきだが。
それをなぜJavaはてんこ盛りにしちゃうんだか・・・
とはいえ、やっぱ言語的にはOOPベースなのがいいなー
文字列とか配列とか基本的なのが、ちゃんとクラス化されてる方が好みだ。
02862502007/12/21(金) 00:22:40ID:???
>>281
ああ、一点補足させてちょ。
この絶対いじらない自動生成部分はクラス丸ごととは限らず関数単位だったりもする。
class Hoge {
// @auto generate start
〜〜〜この中に自動生成コードを吐く〜〜〜
// @auto generate end
}
みたいに、あくまで特殊コメントの中身にだけ吐く。なんで他は好きにコード書ける。
クラス丸ごと吐くと、結局継承しないと機能拡張できないんでやめた、という経緯。
まぁこういうの激しく嫌がる人も多々いるだろうけど。
0287nobodyさん2007/12/21(金) 00:26:37ID:???
>>281
それは自動生成の運用で最低のやり方だと思う。
それなら、自分でも言ってる通り、ライブラリにするべきじゃないかな

自動生成は、あくまでも出来たコードはそのまま触らない、また、
修正があれば自動的に「全て」更新されるっていう前提が無いとただ
コードの行数を増やすだけのものになる、んじゃないかな
0288nobodyさん2007/12/21(金) 00:30:21ID:???
>>287って、考え考え書いてたら本人と激しくかぶった。
250さん熱いなおい。
02892812007/12/21(金) 00:37:47ID:???
>>285
把握、後者のケースだと思ってた
02902502007/12/21(金) 00:38:15ID:???
>>288
なんか荒らしみたいなんで、そろそろ消えますね。
来年はこの手の自動生成ツールをオプソで配布したいな。
ちなみに>>286みたいなの嫌がる人、天下のMSもC#で同じことやってたお。
今はpartial使って別ファイルに吐いてるけど。
0291nobodyさん2007/12/21(金) 00:45:39ID:???
効率化は熱心になると熱いよな。うん。判るよw

>>283
案件のレベルを引き合いに出すのは辞めにしね？

てのはなんか流れ読んでて思った事書き連ねるので長くなるけど、
人数規模での協調やデプロイ効率とかで言うと、OOPやらFW云々より、
例えば言語が静的型付けで堅いかどうかとか、
フローが定石化している環境がいいという話になってくると思うんだ。
そういう点が満たされていれば誰もが幸せかって問うと、Java案件関わった人ならあればみんな首を横に振るでしょw

クリティカルな界隈で人数規模が増えると、出来る奴の柔軟性なんて
どうでもよくて、馬鹿に間違った事をさせない仕組みが重要になっちまう。

PHPのFWの意義を語るスレにおいて、「案件のレベル」ってものすご
暴力的で寂しくなっちまう視点だと思うんだ。
ZendやCake触ってて半端な所あっても「そうそう、こういうので
いいの。こういう程度ので。ありがとZend|Cake」とかない？w
PHPに限らずLL全般だろうけど。

>>290
天下のMSはシステムハンガリアンで血吐いて以降嫌いだw
間違った理屈でも力技で平然と大規模やらかせる好例だよな
いや、個人的に嫌いながらあそこの成果物には感服しきり。
0292nobodyさん2007/12/21(金) 00:59:39ID:???
FlashなニセOO原理主義者の自演が急に消えたなw
荒らしてたDOM厨のテンプレート否定派ともども詫びて吊れよ
0293nobodyさん2007/12/21(金) 01:09:57ID:???
最近のフレームワークはコードジェネレータだけじゃなくて、
コードジェネレータを自作するための機能まであってすごいな。
もうフレームワークを使わない理由なんてないと思う。
0294nobodyさん2007/12/21(金) 01:15:32ID:???
>>287
> 自動生成は、あくまでも出来たコードはそのまま触らない、また、
> 修正があれば自動的に「全て」更新されるっていう前提が無いとただ

自動生成でできたコードを触らないというのなら、
それはscaffoldを使うってことと同意なんだよ。

でもscaffoldだけで作れるものなんてないだろ？
だから、自動生成したものを触る ということは避けられない運命なんだよ。

0295nobodyさん2007/12/21(金) 01:18:53ID:???
>>292
あんたも消えてもいいけどなｗ
FlashもJavaScriptもOO言語ですよ PHPなんかより遙かにｗ
後は使い方だけで(ry
0296nobodyさん2007/12/21(金) 01:21:16ID:???
>>294はここ20スレくらいをもう一度しっかり読むといいと思うよ
また、294が正しいなら、自動生成はデメリットの方が強くなる様に思う
0297nobodyさん2007/12/21(金) 01:24:49ID:???
> それなら、自分でも言ってる通り、ライブラリにするべきじゃないかな

フレームワークにライブラリってのはすでにあるんだよ。
自動生成ってのはライブラリではなく、ライブラリにすることができない
”ライブラリを使うコード”を生成しているの。

ライブラリだけあればアプリが動くかい？
どんなアプリにもありがちなCRUDの動作程度でさえ
ライブラリだけで動くものはない。

フレームワークレベルになるとscaffoldという
ライブラリを使って動作する、土台のコードが用意されるが
scaffold程度の”ライブラリを使うコード”では実用的にはならない。
0298nobodyさん2007/12/21(金) 01:34:35ID:???
やけにscaffoldにこだわる御仁だが、あれは正直デモだろうと思ってる。
それを前提に話をされてもなぁ。
あれで自動生成されてうれしいのは正直Viewおよびページ遷移部分であって、
まちがっても

$param = $request->getParam();
$db->insert($param);

// 以上、俺の妄想フレームワーク

とかいう部分ではない、と思ってるんだがな
そういったところを「自動生成」したいのか？

また、Javaみたいにsetter/getter うるさいところでは、

public function setA($a)
{
　　$this->_a = $a;
}

みたいなものは自動生成されるとうれしいのかもしれないけど
>>297 は違うみたいだし。
（また、出来ればこういうのはクラスの最後尾に３０行くらい改行してつけてくれ、な）
0299nobodyさん2007/12/21(金) 01:44:31ID:???
>>297
フレームワークって言葉を特別視し過ぎじゃないか？
フレームワークなんて結局んところ、特定の設計思想上に
規約や規範をセットにしてライブラリ群を提供しているだけだろ
その観点では齟齬ない話題だと思うんだけど。

>>295
現状のJavaScriptをOOPLって言うと誤解招くんじゃないの。
プロトタイプベース言語はOOPLとして認知されてるけど、
「PHPなんかより遥かに」ってのはいただけない。
実装善し悪しを語ろうにも、クラスベースと単純比較
できるもんじゃないだろう。
：そんなJSもクラスベースになろうとしてるけど、それは別の話

ActionScriptのVMはOOだけど、Flashっていうと製作環境が
混同されて不適切だと思う。
Flex/Airだって環境の名前で余計なもん含むし、現状のFlash
ランタイムはOO化する前のVMも内包してる（上に扱える）しで、混乱招く。
あの界隈、詰まらんところの説明に困るんだよな。mxmlcはjavaだしw
0300nobodyさん2007/12/21(金) 04:08:06ID:???
ここまで全員フレームワークに使われてる奴らばっか
0301nobodyさん2007/12/21(金) 04:26:42ID:???
最強は生PHP
それ以外は馬鹿
0302nobodyさん2007/12/21(金) 04:44:58ID:???
激しく同意
アホどもがスレチな話題をいくらふりまこうが、

結局そこに戻る。
0303nobodyさん2007/12/21(金) 10:05:36ID:???
http://webupd.sv1.sp-land.net/up/201201.jpg
0304nobodyさん2007/12/21(金) 12:01:00ID:???
どいつもこいつも言葉に躍らされすぎ。
全ては結果が良ければなんでもいい。
理屈で間違っていても結果が良ければ問題ない。
実行結果だけじゃなくてメンテナンスや開発効率その他諸々の結果な。

オブジェクト指向だろうとなかろうと、望む要件を満たすならどっちでもいい。
満たせないのにオブジェクト指向のしがらみに囚われて実装しようとしてグダグダとかが一番最低。
んなもん全てツールの一つであって使わないといけないなんて義務もない。
それを使って結果を出せるなら使えばいいし、出せないなら使わなければいいだけの事。
0305nobodyさん2007/12/21(金) 12:19:12ID:???
>>294
こういう発想のやつって、自分の頭で開発効率あげる便利ツールとか作ったこともないんだろうな。
自動生成 = scaffoldしか頭に浮かばない。
それかレスの流れ読んでないか。
0306nobodyさん2007/12/21(金) 19:22:25ID:???
>>294はどうみても
自動生成 = scaffoldでは出来ないコード
ってことを言っているようにしか思えないが？
0307nobodyさん2007/12/21(金) 21:13:22ID:???
彼は、「自動生成＝scaffoldで吐くようなコード」しか頭にないよ、どう見ても。
だから次に、saffoldで吐いたコードに一切手を入れず動かさなきゃいけないような事は、
現実的じゃないとか言ってる。
0308nobodyさん2007/12/22(土) 11:38:25ID:???
>>307
scaffoldで吐いたコードに手を入れないで
使えることなんてあるのか？
普通無いだろ。

お前の仕事はscaffold生成で終わりかよｗ
0309nobodyさん2007/12/22(土) 12:01:32ID:???
つーか、もう池沼だろ・・・全然話がつうじてねぇ・・・
こんなんとFWやらOOPで仕事すんのいやだ
0310nobodyさん2007/12/22(土) 15:38:44ID:???
FWやOOP使う事で「悦に入ってるだけ」の典型的な人達
0311nobodyさん2007/12/22(土) 19:57:49ID:???
そうだね！そのとおりだと思うよ！
0312nobodyさん2007/12/23(日) 03:49:27ID:???
ヒゲデブサスペンダーってCも書けるのか・・・
0313nobodyさん2007/12/23(日) 10:26:49ID:???
フレームワークやオブジェクト指向を使えない人は
落ちこぼれｗｗｗｗ
0314nobodyさん2007/12/23(日) 10:47:58ID:???
python触ってたがたまにphpやったら
昔のセフレとやったみたいな懐かしさがあるな・・・
ビッチだけど嫌いじゃない
糞言語だけど嫌いじゃない
0315nobodyさん2007/12/23(日) 12:19:00ID:???
python（笑）
0316nobodyさん2007/12/23(日) 13:08:30ID:???
php（泣笑）
0317nobodyさん2007/12/23(日) 18:20:39ID:???
Ruby（苦笑）
Perl（微笑）
C#（:-）
0318nobodyさん2007/12/23(日) 19:03:57ID:???
ウェブで使われる言語ってどれもなんかアレだよね
0319nobodyさん2007/12/23(日) 19:10:29ID:???
公平にCとC++、Javaも笑うべきかしら

Cも今となってはシンプルに過ぎる刀だよな
価値あるがいろいろアレだ
C++,Javaも肥大化・煩雑化を免れない代わりにお堅く作れる悩ましいアレさがある

なのでスケープゴートを用意しました。

VB（爆笑）
0320nobodyさん2007/12/24(月) 02:21:44ID:???
PHPはあほでも使えるようにできてるから
暴走させても致命的なことにはなりにくいけど
PHPのゆるい感覚で他の言語使ってたら
メモリ使い切ってスラッシング起こりまくりで鯖にダメージとか受ける
0321nobodyさん2007/12/24(月) 02:24:26ID:???
PHP=はさみ
他のスクリプト言語=カッター
0322nobodyさん2007/12/24(月) 09:51:54ID:???
>>321
便乗してわけのわからんこというな。うんこ。
0323nobodyさん2007/12/24(月) 11:08:21ID:???
PHPはうんこだが、まだ使いようがあるってことだろ
0324nobodyさん2007/12/24(月) 11:24:54ID:???
320を受けてのレスだとすると、カッターな他言語よりはさみなphpの方が安全だ、と言いたいのかもしれず、そうでないかもしれず
0325nobodyさん2007/12/24(月) 15:29:48ID:???
もう言語はpnutsとかでいいよ
0326nobodyさん2007/12/24(月) 17:16:28ID:???
なんかフレームワークを語るのか言語を語るのか分からなくなってきたな。

PHP的にどんなフレームワークがあればみんな楽できるんだろうな
0327nobodyさん2007/12/24(月) 17:21:49ID:???
ストレスなく、楽にプログラムが出来ればいいだけです。
だから、PHPのフレームワークについて語ろうぜ
0328nobodyさん2007/12/24(月) 20:26:21ID:???
唐突っぽいが、PDOって使い物になるの？
試しに触ってみたぐらいでは特に不都合な所は無かったんだけど、バグがどうとかいう
評判も見るし。

普通に使えるのなら、ネイティブで組み込んでいるZend Frameworkがとても気になる。
RepositoryとかConfigとかわかりやすい部分が好感持てる。
0329nobodyさん2007/12/24(月) 20:36:20ID:???
流石に実際に使ってみろとしか言えないな
俺が匿名で保証したところで意味ないっしょw
俺はzfを社内向けwebツール製作で便利に使ってるけど、
PDOに限らずzfは顧客向けアプリへの適用は検討してないな。
俺の良く判らんところでDBコケて、うちの鯖缶が
リコンパイルで死んでた

バグ評判に留意しつつ、自分で試行錯誤できるなら使い物にできるでしょ。
mbstring関係で困った時期に比べたら、まぁなんというんでしょうか、いいんじゃないですかね
こんな日のこんな時間にもコード書いてる自分をまあ言い聞かせてます

バグのない世界はありますか
海は死にますか
0330nobodyさん2007/12/24(月) 21:13:55ID:???
レスthx
まあそうなるんだろうけど ＞ 使ってみろ

思ったが、今のPHPは（やっと）本当に過渡期で、ストレス無く云々、っていうのは
フレームワーク無しも含め、PHP5限定でやりたいような
例えばベタで書くにしても、PHP5の方がPHP4よりやりにくいって事はなさそうだし

ZendFrameworkの読みやすさの半分くらいは、PHP4を切り捨てたところにある気もする
0331nobodyさん2007/12/25(火) 07:11:53ID:???
俺も社内用でしか使ったこと無いけど、PDOが原因でどうかなったことは一回もないな。
0332nobodyさん2007/12/25(火) 11:40:09ID:???
ZendFW使ってる人に質問なんだけど、PHPの関数って失敗したときfalse返したりするだけじゃん？
でもPHP5なら例外使うべきだよね？
自分がつくる範囲では失敗したときに例外投げるようにしてるけど、PHP5より前に作られた関数やクラスとはどう折り合いつけてるのかな。
0333nobodyさん2007/12/25(火) 12:01:46ID:???
エラーハンドリングして例外投げ直したらいいんじゃね？
0334nobodyさん2007/12/25(火) 19:23:08ID:???
>>333
まあそうなんだけど、みんなそうやってる？
なんかすごく面倒なんだけど。どうしてもthrowとdieが混じってしまう。
0335nobodyさん2007/12/25(火) 20:57:56ID:???
その場の面倒云々よりあとのラクさを取るべきでは
0336nobodyさん2007/12/25(火) 21:05:16ID:???
>>332は単純に例外を使うべきところと、そうでないところの区別がまだついてないってことではないかな。
自分で組み上げた部分に関しては、例外ってのはあくまで想定外の事が起きたときに投げるってしておくとよいよ。
でcatchする場所は基本一カ所に統括、そんで、そこでエラー出力。
たとえばstrposとかで、この局面では必ず検索対象文字列が見つかるはずなのに
falseがかえってきちゃったときは、それ以上アプリとしての処理は続けられないので
例外を投げるようにする。
falseが帰ってくることも想定できるなら、そのときの処理もしっかり書く。
dieは使わない方針でいいと思うよ。
■ このスレッドは過去ログ倉庫に格納されています