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

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

[前50を表示]
200:nobodyさん
07/07/07 10:13:33
うん、むしろ、なにも考えずに使えてしまうよ。

symfonyに実装されてる機能を「そこそこ利用できる」学習する時間
＜Cake（とかCIとかライトウエイトのＦＷ）を使って自作点検する時間

って感じだから、symfonyは「退屈」なのよ。でもそれくらいならsymfony
よりは今後はＺＦ使いたい気がする。

201:nobodyさん
07/07/07 11:01:17
ZFはあんだけ時間かけてあのザマだからなあ

202:nobodyさん
07/07/07 11:10:13
ん、ZFわるくないじゃん。機能もそろってるし。
どこが「あのザマ」なの？

203:nobodyさん
07/07/07 11:30:41
ZFがJAVAライクなフレームワークになってるのも分からず、叩きたがってる中二病なので、ご勘弁ください。

204:nobodyさん
07/07/07 11:32:56
ZFはフレームワークって言うより
ライブラリ感が強いから
自前で用意しなきゃいけないことが多い
ソースは読みやすい

205:nobodyさん
07/07/07 11:45:21
symfonyあたりからZF見て足らないっていう部分が、
本当にＦＷの必須要素なのかが疑問だけどね。

206:nobodyさん
07/07/07 12:53:56
別にsymfonyを叩きたいわけじゃないがsymfony信者多いな

207:nobodyさん
07/07/07 13:00:32
PHP4って今でも多くのサイトで使われてるだろ。
PHP5はメモリを食いすぎるからね。
シンフォニーみたいな高機能なフレームワークはエクステンション化しないと実用的でないね。

208:nobodyさん
07/07/07 14:28:41
> PHP5はメモリを食いすぎるからね。
具体的な数字希望

209:nobodyさん
07/07/07 15:16:07
海外国内問わずPHP4互換のFW未だにアップデートし続ける
FWの作者に告ぐ、はっきり言って老害だ、とっとと辞めてくれ
少しでもPHPの未来を考える気があるなら
そのサポート対象から4を切れ、今すぐに

そしてその4互換FWで未だに4のコードを書きつづけるユーザの人達、
4のコードでそのFWの使い方やサンプルをブログに書きつづける人達、
5のサポートをしないレンタルサーバ管理者の人達、
どうか心改めこれから5をインストールして5のコードを書くか
PHPを捨て去るかどちらかを選択して欲しい

これ以上4のコードを生産するべきではない
これ以上4のコードを書く人間を生産するべきではない
これ以上4のコードを書く人間を放置していてはいけない

PHPユーザは尊厳の意をもって4を葬り去るべき

210:nobodyさん
07/07/07 15:51:51
>>209
4のコードはたいがい5でも動くだろ・・。
5を普及させたいなら、レンサバ屋に5を入れるように頼んどけ。
そして君は自分の愚かさを自覚してもっと謙虚になりなさい。

211:nobodyさん
07/07/07 15:57:10
仕事であの中途半端なオブジェクト指向をさわりたくない。

212:nobodyさん
07/07/07 16:45:01 ORHn68Tc
PHP5は最近レンサバでも入ってるよ。
ってか、最近は最悪でもVPS以上を使わせることにしてる。

213:nobodyさん
07/07/07 22:00:26 9N+o65yz
　最近symfony使い始めて、掲示板なんか試しにつくってみたけどさ、
設定ファイルでだいたいの調整ができるから、実際のビジネスに使う
には、結構いいんでは？
　ビジネスでは、スピードよりも保守性が重んじられることも多いから…。

214:nobodyさん
07/07/07 22:12:49
そうね。
何年も保守していくことを考えると、今さらphp4 てどうだろう。。
ていうか数年先にphpはどうなっているんだろうか。

215:nobodyさん
07/07/07 23:46:32
php6でまた仕様が変わってうんざりしてrubyに

216:nobodyさん
07/07/08 01:50:14
ruby 2 で仕様が変わってうんざりして pythonに

217:nobodyさん
07/07/08 01:55:49
一方perlはのんびりと静かに暮らしていた

218:nobodyさん
07/07/08 03:09:35
>>214
そもそもweb業界なんてリアルタイムで変わるものなんで
数年先なんて考えるだけ無駄。

219:nobodyさん
07/07/08 05:34:20
209の駄文にワラタ(笑)

220:nobodyさん
07/07/08 12:19:25
PHP4 is dead, long live PHP5!

221:nobodyさん
07/07/08 12:22:42
次のPHPにレキシカル変数、パッケージが導入されない限り、軽いPHP4で十分だな。

222:nobodyさん
07/07/08 13:46:19
php4が軽いとか思ってる奴まだ居たんだ…

223:nobodyさん
07/07/08 15:11:30
軽いPHP4で十分だよ！

224:nobodyさん
07/07/08 15:53:46
>>222
php4が軽いとか思ってるのではなく、軽いPHP4で十分なのではないか？

225:nobodyさん
07/07/08 16:23:47
じゃあ軽いPHP5でいいじゃん

226:nobodyさん
07/07/08 19:31:40
>>208
ペチパーは自分で調べることが出来ないのかねえ。
↓これでPHP4と5で計ってみろ。
ps -eo vsz,command | grep httpd | awk '{sum+=$1}END{print sum}'
PHP5はこのでっぷり太ったプロセスでHTMLも画像も処理しないといけないんだ。
もっともYahooみたいにモジュールを全部外してコンパイルすれば4も5もそんなに違わないのかも。
が、ビジネスロジックをエクステンションに任せるというのは極めて例外的なPHPの使い方だから参考にならないな。

227:nobodyさん
07/07/08 20:40:27
おまえら4と5の負荷の差がボトルネックに感じる程の
WEBアプリを作ってんのかと小一時間問い詰めたい

例外処理とマジックメソッド使えるだけでも
どれだけ開発が楽になって生産性上がると思ってんだよ
微々たるPHPのバージョン差の負荷とか考える前に
自分が開発するためのフットワークを
軽くすることを先に考えるのがプログラマだろうが

228:nobodyさん
07/07/08 21:12:47
富豪的発想が主流になるのはまだまだ先ってことだね。

目の前の負荷を軽くすることが優先されて、
それに割く労力を別の改良に振れるのに気づけない。

229:nobodyさん
07/07/08 21:20:14
>>226

バージョンで要求される標準モジュールがコンパイル時に違うのにあれこれ言うお前こそばかだろ

230:nobodyさん
07/07/08 22:37:30
ウェブアプリが複雑であるかそうでないかは関係ないよ。静的なHTMLでも画像でも同じこと。同じApacheを使うんだから。
むろんJavaのコンテナやfastcgiのように独立したアプリケーションサーバを用意して、ウェブサーバと分離できればいいんだが、そのコストがPHP5導入のメリットに見合わないつーこと。
バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
それは、確かにVistaには目新しい機能があるが、重くてバギーだし、XPは安定していて困ることはないよ。っていうのと似たような話。

231:nobodyさん
07/07/08 22:45:45
パーソナルユースのOS話しと業務ベースのPHP導入の話しとを一緒にしてるってのが輪をかけてバカ

232:nobodyさん
07/07/08 23:22:56
> バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。

すごーーく単純な理由で、
ひとつのapacheで共存できないから。

重いから5にしないって話はほとんど（皆無ではない）聞かないね……

233:nobodyさん
07/07/08 23:33:37
PHP4 is dead ＝ PHP is dead

　　　　　　ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
　　　　　　＼　　　　PHP is 全部 dead♪／
　　　　　　　　　♪＼(^o^)　♪
　　　　　　　　　＿　 ) 　> ＿ｷｭｯｷｭ♪
　　　　　　　　／.◎。／◎｡／|
　＼(^o^)／.|￣￣￣￣￣|　 | 　＼(^o^)／
　　　 )　 )　 .|　　　　　　　|／　　　ノ　ノ
((((　 >￣ > ))))　＼(^o^)／　(((　<￣<　))))
　　　　　　　　　　　 )　　)
　　　　　　　　　(((　　>￣ > ))))

234:nobodyさん
07/07/08 23:39:25
＞PHP5への移行が進まない
そもそも、これがどれだけ説得力を持つはなしなのかね。
個人レベルのPHPサイトとかが多いからそうなってるだけだろ。
業務ベースなら、新規は５が当然。既にあるやつもそれなりにリニューアルするなら５で
動かすようにリファクタかけるよ。

235:nobodyさん
07/07/09 00:20:13
PHP4脂肪→
オブジェクト指向が理解できない大多数のプログラマ（PHPerの80％）の離脱→
PHP脂肪

236:nobodyさん
07/07/09 07:09:04
drupal使ってるやついねーのかな
結構色々できると思うんだけど

237:nobodyさん
07/07/09 08:16:21
drupalはフレームワークなわけ？
何が魅力なの？
Webページつくるだけなら違うcmsあるし、Webサービスつくるなら足りないだろ？

238:nobodyさん
07/07/09 09:11:54
URLﾘﾝｸ(en.wikipedia.org)
にweb application frameworkって書かれてるよ
魅力はより少ない手間で作れたり、
高負荷のサイトで使われてたり、他のCMSより拡張性が高かったり。
cckとか色々モジュールがあるし、足りなければモジュールを作って拡張できるから
よっぽど複雑なことをするのでない限り、
大抵のことはdrupalでもできると思うんだが

Webサービスとかはできるかどうかわからないから、「結構」って表現にしたんだけど。
完璧じゃなくても、ほとんどの場合に十分使えればいいんじゃないかと

239:nobodyさん
07/07/09 09:14:01
すれ違い、それいっちゃ、XOOPSだって、フレームワークだろ。

240:nobodyさん
07/07/09 09:25:18
>>239
やっぱそっか。スマソ
でもフレームワークとの境界線って曖昧な感じになってきてるよね

241:nobodyさん
07/07/09 09:55:48
ＣＭＳがMVC意識せずにどんどん肥大化していく中で、今で言うフレーム
ワークが展開していったっていう時間の流れだよ。自分はDrupalはその
最中に出てきた「スマート」なＣＭＳ奴で、XOOPSは一時代前のカオスCMS
っていう押さえをしてる。

242:nobodyさん
07/07/09 10:11:55
もうｶｴﾘ
ｽﾚﾘﾝｸ(php板)

243:nobodyさん
07/07/09 20:20:17 sJXKqrgb
>>232
それあるなぁ。そこを簡単に共存できるようにしてれば、
余裕でPHP5が使えるようになったし、PHP4のコードもそのままにできた。

244:nobodyさん
07/07/09 21:22:09
共存なんか大した手間じゃない。

245:nobodyさん
07/07/10 21:53:08
まあriverse proxyとか含めればいくらでも出来るからなあ。

246:nobodyさん
07/07/10 22:30:17
大した手間かけずに共存環境に移行できるサービスばかりだったらそれでよかったんだろうさ

247:nobodyさん
07/07/10 22:58:26
？言ってる意味がわからん

248:nobodyさん
07/07/12 22:09:49
>>241
Drupalは何が「スマート」なの?
XOOPSはコード的に古いから乗り換えるか
ZFあたりで出てきそうなCMSを探すか考えているところ

249:nobodyさん
07/07/12 22:47:39
CMSなんか使ってるやつはくず。
コード気にする価値なし。

250:nobodyさん
07/07/12 22:49:58
249はよくいるような「皆が使ってるものを否定する自分ｶｺｲｲ」なお子様に見えなくもないが
重厚長大なフルセットCMSって今もうそういう対象でもないよな

251:nobodyさん
07/07/12 22:51:34
どのFWもプレゼンテーション層がお粗末なのがどうもなぁ。
Smartyとかデザイナにしてみたらえらい負担だろうし。
もっと連携のしやすいものがあればいいんだけど。

252:nobodyさん
07/07/12 23:00:41
>>249
頭堅いなあ
出来上がるもんが結局同じなら、車輪の再発明しなくてもいいのに

253:nobodyさん
07/07/12 23:18:40
今日びＰＨＰもできないデザイナーは死滅したらいいよ

254:nobodyさん
07/07/12 23:30:31
>>253
お前がな

255:nobodyさん
07/07/12 23:36:15
うむ。今更感の漂う話題ではあるが
俺もついでに今更感の漂う話を投下しとくか
　
　
　
　
おまいら、CMSが好きならZope + Ploneが最強じゃね？

256:nobodyさん
07/07/14 16:14:49
PHP4サポート打ち切りって影響甚大じゃね？
稼動してるサイトは膨大で
そのうちPHP5に移行できるのはどれだけあるのか？
サイバーテロが吹き荒れそう

257:nobodyさん
07/07/14 16:36:57
正直遅いぐらい
ようやく4排除への大義名分を得られるわけだ

258:nobodyさん
07/07/14 17:44:07
これで4しか入ってなかったレンサバも5に切り替わるといいな。

259:nobodyさん
07/07/14 18:32:17
今PHP3で走ってるサイトってどのくらいあるのかな

260:nobodyさん
07/07/14 18:36:19
4から5のリプレースがうまくいかなかったのを教訓に
6は5と共存できるような仕組みが欲しいところだな

261:nobodyさん
07/07/14 18:48:36
「仕様が完全上位互換」とかじゃダメなんだよな
共存させたい環境のひとは新環境での再テストとかもしたくないだろうし

262:nobodyさん
07/07/15 00:13:42
そもそもそのテスト費用が出して貰えないから困るわけで。

263:nobodyさん
07/07/16 23:55:55 jJDluNIm
皆さん地震大丈夫ですか？
NTTの災害用ブロードバンド伝言板（web171）はPHPなんだね。
不謹慎かもしれないけど、ちょっと嬉しい…。

264:nobodyさん
07/07/17 11:54:09
そうかな? PHPだと大規模災害時とかでロードが大きくなったときに
ホイホイとスケールできるのかちょっと心配な気が...

265:nobodyさん
07/07/17 12:08:08
スケールできるよPHP

266:nobodyさん
07/07/17 14:31:06
サーバ、ネットワーク周りの改善でなんとでもなる。

267:nobodyさん
07/07/17 17:20:35
>>251
連携のしやすいものって例えばどんなもの?
php直書きとsmarty以外の簡単な方法って浮かばないんだけど

268:nobodyさん
07/07/17 17:32:55
もっと直感的に使える高機能な独自タグってことだろ。MTみたいな感じじゃないか？

269:nobodyさん
07/07/17 19:53:06
>>251が曖昧で分からないが
連携に関しては基本デザイナに埋め込みさせなきゃいいと思うんだが

270:nobodyさん
07/07/18 00:09:10
そんな事いってるから日本のPHPサイトは手抜きデザインばっかりなんだが

271:nobodyさん
07/07/18 00:32:13
>>270
なんでそうなるんだよｗ
デザイン→HTMLコーディングまでデザイナ側で落とし込んで
PHPの埋め込みだけプログラマがやればって話なのに
「そんな事いってるから」の後になんで手抜きデザイン？

272:nobodyさん
07/07/18 03:49:36
あとで修正はいったらどうすんの？

273:nobodyさん
07/07/18 09:01:06
適時対応
静的部分だけの修正でデザイナだけで
修正できるようであればデザイナが修正
修正箇所に動的な部分を含んで
埋め込みコードの修正も伴うのであればプログラマが修正
で、なんか困ることある？

274:nobodyさん
07/07/18 11:00:52
結局デザイナーっていらないね

275:nobodyさん
07/07/18 11:14:27
状況から真っ当な結論を導き出すのが極端に下手な奴がいるな

276:nobodyさん
07/07/18 11:31:24
まともにデザイナと連携して仕事したことないんだろうな

277:nobodyさん
07/07/18 16:25:07 3R7D5ath
SmartyのかわりにPHPTALとかじゃだめなの？

278:nobodyさん
07/07/18 17:49:45
デザイナーと仕事するのが偉いと勘違いしてるやつがぽつぽつ

279:nobodyさん
07/07/18 18:40:20
自分が一番偉いんだと勘違いしてるやつが・・・

280:nobodyさん
07/07/18 18:43:56
コーダーでPGもこなす俺が真の勝ち組。
デザイナにはデザイン画像だけ描いてもらえばおｋ。
HTML起こすのは自分でできるもん♪

281:nobodyさん
07/07/18 18:45:26 sJyKZns/
全部一人でやれる奴が最強な訳で・・・

282:nobodyさん
07/07/18 18:49:11
実際ヘタな紙デザイナに変なHTML書かせるより
画像だけ描いてもらってHTMLに起こすのはプログラマがやった方が
結果としてキレイなものが出来上がる気がする

283:nobodyさん
07/07/18 19:17:22
ズレてきてるな
どう役割分担して連携するかって話だろ
誰が偉いとかおまえらのHTMLコーダー自慢とかはどうでもいいよ

284:nobodyさん
07/07/19 10:09:35
読みこみファイル数がすごい数になってるんだけど
アクセラレータつこうたら大丈夫？
お前らどうしてますか？

285:nobodyさん
07/07/19 12:33:42
>>284
まずコードを見直す

286:nobodyさん
07/07/19 14:46:00 Qs6wUD6U
>>284
主要フレームワークってeaダメだよね？

287:nobodyさん
07/07/19 15:12:56
cakeはいけてますが

288:nobodyさん
07/07/19 21:29:14
なんでeaってダメなの?
xcacheならOK?

289:nobodyさん
07/07/19 21:44:14
異常動作することがあるらしいね>ea
アクセラレータのスレにあったはず
別にフレームワークは関係ないと思うが

290:nobodyさん
07/07/20 04:21:50
>>285
フレームワーク自体がファイル読みこみまくりだからコード見直しても意味ない
hello,worldですらファイルが数十個読まれる
つまりフレームワーク使うのは阿呆
ついでにいえばウェブプログラムごときでオブジェクト指向使うやつも阿呆

291:nobodyさん
07/07/20 04:56:45
とオブジェクト指向が理解できない阿呆が申しております。

292:nobodyさん
07/07/20 09:49:57 xk3U0lu8
protectedな変数持ってるとEA動きません。

293:nobodyさん
07/07/20 10:14:17
まじで？
俺オワタ＼(^o^)／

294:nobodyさん
07/07/20 10:19:26
本当に必要なファイル読み込みなのかどうかコードを見直せ。
ＦＷ側で不要なインスタンスを発行しまくっているようなら、
それをコロすように継承自前クラスで上書き。
ＦＷって結局汎用だから、MVCの過程で、余分な処理をしてることが往々にしてある。
次に、ページキャッシュを考えろ。キャッシュ処理可能ページとそうでないページの
振り分けをちゃんとできるようにコードを見直す。
アクセとかハードウエア性能向上という手がつかえないなら、それしかないだろう。

295:nobodyさん
07/07/20 10:35:03
気にしないのが一番

296:nobodyさん
07/07/20 12:42:12
inodeは上限あるけど
オープンできるファイルに上限てあんの？

297:nobodyさん
07/07/20 12:59:27
少なくともlinux, bsdにはある
windowsは知らん

298:nobodyさん
07/07/20 14:44:44
>>292
いつの話よ？ 0.9.5.1 では直ってる。

299:nobodyさん
07/07/20 21:35:41 g4/DmFJL
>>298
protectedの件は直ったらしい。
でも、例外キャッチできないんだって。
URLﾘﾝｸ(d.hatena.ne.jp)

300:nobodyさん
07/07/20 21:40:09
>>299
オプティマイザのバグということは、オフにすれば (eaccelerator.optimizer = 0) おｋ？
キャッシュの恩恵は受けられるし。

301:nobodyさん
07/07/20 21:53:04
だいたいPHPはバギーすぎるんだよ。何、PHP5は安定しているので、PHP4は開発中止？こっちはキムチパッチ当ててる所だ。

302:nobodyさん
07/07/20 22:17:02
>>299
それは使い物にならんな・・・

303:nobodyさん
07/07/21 02:40:16
オプチマイザなんてたいした効果もないんだからオフでおk

304:nobodyさん
07/07/21 05:04:00
ポン入れでまもとに使えない時点でアウト。
たまに案件でphp.iniをグチャグチャいじってさらにPHP_VALUEまでいじってるあるのに遭遇するが、
開発サーバで再現しきれん設定とかがあってむかつく。

305:nobodyさん
07/07/21 10:31:30
アウトならこんなところまで来てネガってないで他の言語使えばいいじゃん……
何がしたいんだ？
再現しきれんってのは「設定できる場所を自分が把握できてない」って意味なだけだろ？

306:nobodyさん
07/07/22 08:29:26
O/Rマッパって何のためにあるんだ？
返り値がオブジェクトの配列である必要性がねーだろ
普通の連想配列で何の問題もない

307:nobodyさん
07/07/22 11:19:49
>>306
OOP的にかっこいいから、とかそういうことなんじゃない？
たぶんOOP的なものと非OOP的なものが混在するのを嫌ってるんだろう。

308:nobodyさん
07/07/22 11:31:11
ＯＯＰのためにマッパが作られてるんだけどね。

309:nobodyさん
07/07/22 12:26:09
何の問題もないなら使わなきゃいい
まあそれをわざわざここに書いてる事自体
「なんでO/Rマッパがいいのかわかりません」
って書いてるようなもんなんだけどねｗ

310:nobodyさん
07/07/22 12:41:59
>>309
お前も分からないんだろ
強がるなよ

311:nobodyさん
07/07/22 13:03:41
>>310
普通に使ってるよ
てかO/Rマッパのメリットが分からないとか
O/Rマッパ使う理由がかっこいいからとか
そんなレベルでFWのスレに来る奴ってなんなのｗｗｗ

312:nobodyさん
07/07/22 13:05:08
>>311
メリットが分からないまま使ってるんだろ
やせ我慢乙ｗｗｗｗ

313:nobodyさん
07/07/22 13:28:44
Oは、おぶじぇくとのおー

314:307
07/07/22 13:30:46
そういやFWのスレだったｗ

315:nobodyさん
07/07/22 17:05:31
ヘルパーってかっこつけて言ってるけど単なる関数なんだな
本来viewのものなのに
グローバルスコープにあるのもダサいことこの上なし

316:nobodyさん
07/07/22 17:07:10
オーバーライドできないのもまたビッチなり

317:nobodyさん
07/07/22 17:22:22
それはおれも思った
ただのグローバルスコープにある関数がいつのまにヘルパなんて呼ばれて美化されてんだ，ってｗ

変数は view 展開時のみグローバルスコープに登録されるものが多いようだから
関数もそうするようになってるフレームワークがあってもいいように思うが
パフォーマンスとか色々の面で現実的じゃなさそうかな……

318:nobodyさん
07/07/22 17:32:02
CakePHPとかsymfonyのヘルパーってクラスじゃなかったっけ

319:nobodyさん
07/07/22 17:34:57
rubyみたいにレシーバが省略できないから
railsのviewライクに使えるよう突き詰めた結果がああなったと思われる
まあ早い話が$this書きたくないっていうことだな

俺もview helperとはいえ単なるfunctionにするのは好みじゃないな
ZFのview helperはクラス（オブジェクト）になっている
view helperがfunctionになってるのはsymfonyだっけ？他にもあるかな

320:nobodyさん
07/07/22 17:36:07
>>318
cakeは見たことないけどsymfonyは関数だった

321:318
07/07/22 17:39:28
あ、symfonyはfunctionか。ごめん

322:nobodyさん
07/07/22 17:40:35
cakeはクラス。CIは関数

323:nobodyさん
07/07/22 17:45:28
関数使うFWでも
読むファイル指定してるだけだからstaticなクラス書いてもいいけどね

324:nobodyさん
07/07/22 17:47:58
staticなクラスにしちゃうと今度は使う時名前が長くなるんだよ
phpのどうしようもないところｗ

325:nobodyさん
07/07/22 17:50:08
でも俺はstaticなクラス作って書いてる。
後から一括置換なんかも便利だし。

326:nobodyさん
07/07/22 17:59:50
俺は関数でもいいと思う派だけど、
関数の場合、初めから用意されてるヘルパーがFW側に置いてあるのはどうかと思う。
コマンドでアプリケーションのディレクトリ構造を展開したときに、アプリ側に展開して欲しい。

クラスにした方がいいと思ったらクラスを作る。libなイメージ。

327:nobodyさん
07/07/22 18:03:24
staticクラスで、ヘルパー関数を一旦ラップするのをお勧めする

328:nobodyさん
07/07/22 18:10:22
viewにview helperがmixinされるような形のが一番いいよ
$thisを書くのは必要経費で

329:nobodyさん
07/07/22 18:19:34
うーんmixinかー
メソッド名が元のviewと被ったら？

330:nobodyさん
07/07/22 18:33:50
unit test時にわかるでしょ

331:nobodyさん
07/07/22 18:56:57
>>327
意図は？

staticクラスというのはstaticメソッド群からなるクラスのことだと思うが、
staticメソッドでラップしても関数を関数でラップするのと変わらない。

クラスの(static)プロパティも使用しいくつかのヘルパー関数群を
関連するものとして扱うなら、それはstaticよりもインスタンスにして
投げるインスタンスで振る舞いを変えられるようにしたほうが意味があると思うのだが。

332:nobodyさん
07/07/22 19:04:54
そこまでやるなら、既存のヘルパ関数なんかそもそも使わん。ヘルパー用クラスを
書くよ。保守を考えてstaticにするのは同一関数（メソッド）名で、とりあえずヘルパ使ってるってことを
明示しつつ拡張するため。関数を同一関数名でラップすることは出来ないからね。

333:nobodyさん
07/07/22 19:18:21 3PPkob3E
単にネームスペースの代わりだね。俺もやるよ。

334:nobodyさん
07/07/22 19:28:48
まあFW側で直接定義されてるfunctionじゃな
オーバーライドすらできんしな、FWのソースを書き換えとか御免だ
ラッパーがstatic/dynamicどっちがいいとかは抜きにして
ラップして使う事自体に意味はちゃんとある

335:nobodyさん
07/07/22 19:34:02
関数だとどこで定義されているか、わかりにくいしねえ。

336:nobodyさん
07/07/22 19:37:03
うん、grepすりゃいいからそれは別に困らないがｗ

337:nobodyさん
07/07/22 19:50:04
関数ヘルパでも接頭辞付けたらラップできるな

338:nobodyさん
07/07/22 20:44:06
～～すれば～～が無くてもおｋ
って発想を減らしていかないと「誰でも使えるフレームワーク」にならないんだろうね
わかってる人だけでいじるならこの思想の方が楽でいいんだがｗ

>>319
CodeIgniterも関数じゃなかったかな？

339:nobodyさん
07/07/22 20:56:10
「誰でも使えるフレームワーク」とか要らん

340:nobodyさん
07/07/22 22:16:39
誰でも使えないフレームワーク誕生の瞬間である

341:nobodyさん
07/07/23 00:56:07
>>317
変数はグローバルスコープに登録されてるわけじゃないよ
メソッド中のローカルスコープにテンプレートを読み込んでるだけ。
テンプレートを基準にして見るとグローバルスコープかと思えるけど。

342:nobodyさん
07/07/23 07:09:56
>>338
ＦＷが機能を実装してなくてもいいんじゃないのかね。
外部ライブラリの導入やユーザ拡張がしやすい設計（ＭＶＣが可能な限り疎結合的）
であることが、いいＦＷの第一条件だと思うよ。
その上で個別に、ＸＸのルータクラスは使いやすいとか、モデルが書きやすいとか、
そういう評価が出てくると思う。

343:nobodyさん
07/07/23 12:45:58
>>342
ＦＷとは何か？を理解してないやつが語ってるんだからしょうがあるまい。

こう書くと誤解を招く恐れもあるんだが、「仕様こそがＦＷである」とでも書いておくかな。
じゃないと、いつまで経ってもＦＷとライブラリの違いも判らん奴が妙な書込みを続けるし。

344:nobodyさん
07/07/23 20:12:12
＞仕様こそがＦＷ
ﾜｹﾜｶﾗﾝ

345:nobodyさん
07/07/23 21:56:37
こう書くと誤解を招く恐れもあるんだが、
「『仕様こそがFWである』こそ妙な書込み」とでも書いておくかな。
じゃないと、いつまで経っても妙な書込みとそうでない書込みの
違いも判らん奴が妙な書込みを続けるし。

346:nobodyさん
07/07/23 22:58:29
フレームワークこそがＦＷである。

347:nobodyさん
07/07/24 01:46:05
最近出てきてるとかを見ると、バッドノウハウの温床だな。

348:nobodyさん
07/07/24 02:52:11 Wl3XMVYJ
Fireworks

349:nobodyさん
07/07/24 09:36:30
Firewall

350:nobodyさん
07/07/24 11:38:30
Frank Williams

351:nobodyさん
07/07/24 11:45:34
>>347
たとえば？典型例は？

352:nobodyさん
07/07/24 12:58:42
for ( $i=0,$count=count($contents); $i<$count; $i++ ){

}
ループ中のカウントを減らすためにこういう書き方すんのって
バッドノウハウですか？普通にあり？

353:nobodyさん
07/07/24 13:07:30
>>352
アリじゃね？

354:nobodyさん
07/07/24 13:35:50
「for文の条件内でcount()を使うな」はバッドノウハウではないと思うけど
その書き方はどうかと……

$count=count($contents);
for ( $i=0; $i<$count; $i++ ){

}

の方が見る人が理解しやすいと思うなぁ

355:nobodyさん
07/07/24 14:12:03
激しくどっちでも良過ぎて溜息が漏れる

356:nobodyさん
07/07/24 14:12:23
なにが「どうかと……」だよ。いたって普通だろうが。

357:nobodyさん
07/07/24 14:33:10
ワンライナーで書けるものは書けばいいじゃんっていう空気が
phpはあんまりないよな言語仕様による要因が大きいけれども
rubyとかは仕様も使う側もそういう空気に満ち溢れてるから
コードは短いけど行単位の情報量が必然的に多くなる

358:nobodyさん
07/07/24 14:44:56
forの式1はカンマ区切りで複数とれるのね。しらんかったよ。

359:nobodyさん
07/07/24 14:49:19
>>352
forループで関数呼び出しを避けたほうがいい
URLﾘﾝｸ(lint.s1.x-beat.com)

360:nobodyさん
07/07/24 15:02:17
>>359
せっかくだから環境も分かるようにしてくれよ。
いつのベンチかわからん。

361:nobodyさん
07/07/24 15:04:45
>>359
>>352 の関数呼び出しは、評価部分ではなくて、初期代入部分だから、
そのベンチはあてはまらんだろ？

362:nobodyさん
07/07/24 15:19:32
>>359
よく読め

それを避けたいから
for ( $i=0; $i<count($contents); $i++ ){
でなく
for ( $i=0,$count=count($contents); $i<$count; $i++ ){
なんだろ

363:359
07/07/24 15:22:22
>>361
>>352の書き方でいいよといいたかった

364:nobodyさん
07/07/24 19:12:05
たしかに、自分がPHPで書くときは出来るだけワンライナーは避けてるなぁ。
他者が関わる場合は、極端に言えば本当の初心者が見ても解るように書いてる。
コードの「格好良さ」より、「解りやすさ」重視って感じかな。

365:nobodyさん
07/07/24 19:56:24
俺もそう。
なんかワンライナーの方がかっこよくみられるけどね。
わかりやすい方がいい。

Rubyみたいに . で右につないでいけると、
ワンライナーも使いやすくなるんだけど。

366:nobodyさん ◆wSaCDPDEl2
07/07/24 20:10:07
ワンライナーでなんか書いて

367:nobodyさん
07/07/24 21:03:40
おとこわりだ！

368:nobodyさん
07/07/24 21:07:06
どう考えても>>354のほうが視認性があるだろ。

369:nobodyさん
07/07/24 21:31:29
for文のループに関する議論は、確かsymfonyで話題になったことが
あったみたいだけど、コレすなわち「FWを利用することによるバッドノウハウ」
とはならんよね。

370:nobodyさん
07/07/24 22:02:50
一方ロシアは
foreach ($contents as $i => $content) { }
を使った

371:nobodyさん
07/07/24 22:32:45
>>370
なるほど
それいいな
パフォーマンスも問題ない？

372:nobodyさん
07/07/24 22:38:28
それは、パフォ的にありまくり。使っちゃいけないだろうな。

373:nobodyさん
07/07/24 22:44:17
えええええ
ロシア駄目じゃん

374:nobodyさん
07/07/24 22:46:08
手元のテストループで言えば、ロシアは1.5倍増の時間がかかってる。
ロシアの負け。

375:nobodyさん
07/07/24 22:51:50
つーかPHPならforeachふつうに使うだろ。。
おまえら本当にPHP使ってるのか。

376:nobodyさん
07/07/24 22:55:11
連想配列なら使うけど普通の配列なら使わない

377:nobodyさん
07/07/24 22:55:26
for使う事自体が少ないしな

378:nobodyさん
07/07/24 22:59:14
連想配列の話してるわけじゃないんだけどね。

379:nobodyさん
07/07/24 23:06:02
・中身だけ使う
foreach ($array as $value) { }
・キーだけ使う
foreach (array_keys($array) as $key) { }
・両方使う
foreach ($array as $key => $value) { }

for使うってのは滅多にないな
しかしFWのスレなのに重隅論議だな

380:nobodyさん
07/07/24 23:12:00
前にも出た結論な気がするけど
FW使うってだけでそんな重隅最適化なんてぜんぶチャラだよなｗ

381:nobodyさん
07/07/24 23:19:46
最適化っていう視点じゃなくて綺麗で視認性がある書き方したい
ってことで見れば別に重箱でもない。

382:nobodyさん
07/07/25 00:38:21
>綺麗で視認性がある書き方したい
そんなもんPHP使ってる時点で(

383:nobodyさん
07/07/25 00:46:56
お前みたいな思考停止はイラネ

384:nobodyさん
07/07/25 01:11:06
ブロックスコープのある言語の使用者にとっては、ブロック内での使い捨ての変数は初期化式で宣言するのが当たり前なんだけどな。
この辺にペチパーの底力を感じる。

385:nobodyさん
07/07/25 01:34:40
つーか>>370では>>352と挙動が別物なんだがな

386:nobodyさん
07/07/25 02:26:41
人を見下さずに普通に発言できんものですかねおまいら

387:nobodyさん
07/07/25 18:00:18
仕様です

388:nobodyさん
07/07/26 01:09:42
>>351
ページごとにいちいちサブコントローラ(Action)を書かないと動かないような、
無駄にStrutsの汚点を継承しているEthnaとか。

処理系の実装してる組織のくせに言語仕様じゃなくて
コーディングルールでゴリゴリ縛ってるZendとか

しょうもない所でPEAR::DBに依存してるくせにDB::getAll()がラップされてなくて、
結局メンバのPEAR::DBインスタンスに直接アクセスするしか解決方法が無かったりとか

どうせ作業の流れなんて機能単位でしかやらないのに
ファイル構成でモデルとビューのディレクトリががロンドン・パリなみに離れてるわ
さらにそれぞれアクション命名規則に縛られてかなりディープなディレクトリ構成になるわで
Eclipseの画面からはみでてしまって小さい修正のたびに
スクロールバーいじらんなんハメになってたりとか

PHPなんて標準でフォームバリデータとモデル仕様がないから面倒なだけなのに
FWなんて大げさなもんにして一生使いもしないクラスを多重に内包して無駄なメモリ・CPU時間食ってる
PHP用FWの存在意義とか。

389:nobodyさん
07/07/26 01:14:46
今度は>>388が素晴らしいFWを教えてくれるそうです。

390:nobodyさん
07/07/26 01:23:09
ページごとにサブコントローラを書かずに動くとしたらどんなの？

391:nobodyさん
07/07/26 02:59:01
簡単さでいうと、
ちいたん＞CodeIgniter＞CakePHP＞Symfony
ですか？

392:nobodyさん
07/07/26 09:27:58
>>388
最近の、って言っときながらほとんどEthnaの話だけかよｗ
Ethnaみたいな旧態依然なFW使ってりゃそりゃBKだらけになるわなｗ

393:nobodyさん
07/07/26 11:28:09
BKって何？

394:nobodyさん
07/07/26 11:33:52
>>モデルとビューのディレクトリががロンドン・パリなみに離れてる
こんなん自分で変えたらいいだけじゃね

395:nobodyさん
07/07/26 11:47:08
ディレクトリ構成自体がＦＷの設計であるということも
わからない奴はＦＷを触るなよ

396:nobodyさん
07/07/26 11:50:57
こう書くと誤解を招く恐れもあるんだが、「ディレクトリ構成こそがＦＷである」とでも書いておくかな。

397:nobodyさん
07/07/26 11:53:52
>>393
＞Wikipedia項目ﾘﾝｸ
好みのものを選んでくれ

398:nobodyさん
07/07/26 14:20:46
>>388
> 処理系の実装してる組織のくせに言語仕様じゃなくて
> コーディングルールでゴリゴリ縛ってるZendとか
これはまさにその通りだな。
つーか、PHPの開発チームってどういう構成になってるんだ？

399:nobodyさん
07/07/26 14:36:21
>>397
俺はBerryz工房だな

400:nobodyさん
07/07/26 14:37:54
FW（的なもの）ありきなものがいいんなら
勝手にcoldfusionなりwebobjectsなりやってくれ

401:nobodyさん
07/07/26 16:45:14
>>398
コーディングルールでゴリゴリ縛ってるって具体的にどういう所？
クラスの命名規則ってこと？

402:nobodyさん
07/07/26 22:00:26
>>399
俺は美少女教育が気になる

403:nobodyさん
07/07/26 22:03:45
>>401
これらね↓
URLﾘﾝｸ(framework.zend.com)

?>書かないのも気持ち悪い～とか思ってたけど、
自然と書かなくなったな。なんかめんどうだから。

404:nobodyさん
07/07/26 22:31:48
へー。
？＞省略は糞だろうなあ。
単にヘッダの空文字列送出防ぐためにやってるんでしょ？
本末転倒だ

405:nobodyさん
07/07/26 22:59:42
さっさと <?php を省略できるようにしろよ、糞Zend

406:nobodyさん
07/07/27 00:16:54
sigilは好みもあるからどっちでもいいけど、つけるんだったらコレくらいはパースしてほしい。

<?php
$a = array('a'=>1);
print "$a['a']\n";
?>
↑エラー

#!/usr/bin/perl
%a = ('a'=>1);
print "$a{'a'}\n";
↑「1」。当然の勝利。

407:nobodyさん
07/07/27 00:32:26
片方を文法に従わず書いて他方を文法に従って書いて何が勝利なのか全然わからんがｗ
既存の文法が気に食わないならソースにパッチ当ててオリジナルのPHP作って使ったら？

408:nobodyさん
07/07/27 00:57:19
要するにPHPのパーサーがヘボってこと。

409:nobodyさん
07/07/27 01:36:06
要してねーだろ
ヘボいのはPHPの文字列解釈仕様であってパーサはその仕様の通りに正常に動いてるんだろーが
自分が何を気に入らないのかすら理解できてないアフォですか？

410:nobodyさん
07/07/27 01:47:46
仕様って…ｗ。
まあ、PHPはprint $a['a']."\n";とやるしかないわな。
$a = 0 || 100;とか3項演算子の左結合とか、たいそうな仕様だわ。
こういうのが積み重なって、PHPのヘボソースが出来上がる。

411:nobodyさん
07/07/27 02:17:30
print "{$a['a']}\n";
何もそんなに自信満々で無知をひけらかすことはないと思うんだ。

412:nobodyさん
07/07/27 02:19:41
print "$a[a]\n"; もしくは print "{$a[a]}\n";

PHPの糞仕様を擁護する気はさらさらねーが
悪口言いたい一心で研究不足を自慢されてもバカじゃね?としか思えん

413:nobodyさん
07/07/27 02:49:11
>>411
その{}を面倒と思わないなら、それでいいよ。俺はノーサンキュー。

414:nobodyさん
07/07/27 02:51:10
>>412残念
配列ですべきこととしてはならないこと
なぜ、$foo[bar] は使用できないのか?
URLﾘﾝｸ(www.php.net)

415:nobodyさん
07/07/27 09:26:41
>>412は釣りだろ？でなきゃ考え付かない

416:nobodyさん
07/07/27 15:20:29
codeigniterのリンクヘルパの仕様おかしくね？
引数の順序はfunc(label,uri…）だろ、感覚的に考えて。
anchor(uri,label)ってなめてんのかこの野郎

417:nobodyさん
07/07/27 15:44:12
<a href="url">label</a> の順序に従ってるんじゃないか？
感覚の問題だから一概には言えないが俺もlabelが前の方が自然だと思う

418:nobodyさん
07/07/27 15:57:50
<a href="url">label</a>において
href…属性
label…内容
重要度から言えば内容>属性だから、
第一引数は内容=labelがふさわしい

419:nobodyさん
07/07/27 15:59:34
>>416 のanchor(uri,label) しか見てないけど、
labelは省略可能な気がするから（urlで代替できる）、
それでいいんじゃない。
省略可能かどうかは知らんが。

420:nobodyさん
07/07/27 16:00:16
フレームワークでは標準的な、
「mod_rewriteを使ってindex.phpを隠す方式」の正式な名称って何ですか？

421:nobodyさん
07/07/27 16:01:22
>>419
symfony様に喧嘩売ってんのか

422:419
07/07/27 16:05:30
マニュアル見たらurlで代替すると書いてるじゃん。
URLﾘﾝｸ(userguide.cilab.info)
だからこれでいい。

423:nobodyさん
07/07/27 16:15:18
>>420
正確に指し示すこれっていう名前はないなそう言われてみれば
WEBFWのほぼ標準的な仕様なのにな

424:nobodyさん
07/07/27 16:33:38
PATH_INFO方式とはまた別なの？

425:nobodyさん
07/07/27 16:51:30
>>424
PATH_INFOの場合は、..../index.php/foo/barが機能するから直接の関係性はない。

426:nobodyさん
07/07/27 16:58:19
隠れディスパッチャ方式でok

427:nobodyさん
07/07/27 18:39:49
indexの話でもなくて
リライトルータ、URLマッパーの話でもない?

428:nobodyさん
07/07/27 20:18:55
mod_rewriteを使ったフロントコントローラ、かなあ

429:nobodyさん
07/07/27 20:38:49
>>428
機能そのまま説明してるだけじゃんｗ

430:nobodyさん
07/07/27 20:42:59
>>422
ラベルをURL自体にするケースがどれだけあるのかと。
そんなレアケースのために引数の順序が決定されるのは納得いかない
あー納得いかないね

431:nobodyさん
07/07/27 20:54:43
>>427
ゼンブ違う

432:nobodyさん
07/07/27 21:14:22
いってる意味ﾜｶﾗﾝなあ。
URLが先、ラベルが後のほうが直感的にＯＫだろ

433:nobodyさん
07/07/27 21:34:14
まあ、感覚だから個人差はあるな
symfonyはlabel,url
ciはurl,label
他は？

434:nobodyさん
07/07/27 21:38:41
そもそも中に入るテキストを
「ラベル」って呼ぶ事に何の疑問を感じてないおまえらにイライラする

435:nobodyさん
07/07/27 21:42:39
呼んでいる奴に付き合ってあげてるだけだからそこでイライラするな
そんなこといえば「中に入るテキスト」なんてW3C定義と全然違うだろ。

436:nobodyさん
07/07/27 21:42:42
話題を振った416の用語に合わせてるだけだと思うが
そういう434は何と呼ぶのが良いと思う？

個人的には「アンカ」「アンカ文」あたりかと思うが
「ラベル」の方がより多くの人に意味が伝わりそうな気がするな

437:nobodyさん
07/07/27 21:45:46
どうでもいい定義に拘ってる434の方にイライラする
普通に伝わればいいだろ
テーマの中核じゃないんだから

438:nobodyさん
07/07/27 21:55:14
434の人気に、嫉妬はしない

439:434
07/07/27 22:04:29
リアル涙目なんで
引き続き【PHP】フレームワークについて語るスレ7【総合】でお楽しみください

「中に入るテキスト」はねーよ俺、反論できない

440:nobodyさん
07/07/27 22:21:40
泣いてるの？

441:nobodyさん
07/07/27 23:06:40
>>433
cakeのバヤイ
link (label,url)

442:nobodyさん
07/07/27 23:21:22
ZFの場合

リンクのヘルパ自体無い

443:nobodyさん
07/07/27 23:27:43
二大人気FWのsymfonyとcakeが
label,urlを採用しているということは
ciは異端
ZFはなめすぎワロタ

444:nobodyさん
07/07/27 23:29:50
>>416
ヒント：イニシャルは姓と名が逆

445:nobodyさん
07/07/28 02:19:59
CIって規模小さいけど作ってるヤツ頭いいな～。
label,urlは前々から疑問感じてた。

446:nobodyさん
07/07/28 02:55:44
擁護みたいな形になるが、俺も「ラベル」の意味がわからず読んでたが、
434を読んでやっと<a href=url>この部分</a>のことだとわかった
もちろんlink(label, url)ってペアで書いてあればすぐわかることだけど

447:nobodyさん
07/07/28 03:32:53
ciのヘルパが気持ち悪いから
my_anchor作りました(`Д´)

448:nobodyさん
07/07/28 03:36:13
ラベルって呼ぶのは
GUIのプログラミングの文化

449:nobodyさん
07/07/28 09:13:03
>>446
>>417も読まないわけですか？

450:nobodyさん
07/07/28 10:14:49
>>430
そんなにレアケースとも思わないけど。
入力されたURLを<a>タグに置き換える時とかに使わない？

ま、どっちが先だろうがどーでも良いけど、
>>447みたいな事するくらいなら他のFW使えば良いのに。

451:nobodyさん
07/07/28 10:19:23
>>449
そりゃ気付かなかった

452:nobodyさん
07/07/28 10:51:50
>>450
いやいやいや
他のFW使うくらいならヘルパ作る方が断然楽だろ
リンクヘルパの引数の順番の好みのために、学習曲線を登る苦労とか実装されてるユーティリティ機能とかを完全に無視できる奴はそうそういないだろｗ

453:nobodyさん
07/07/28 14:27:44
そのうち誰かがどっちでもいい関数作って、それが後々
セキュリティホールになったりするのがぺちぱークオリティ、
とか言ってみる。まぁ、冗談だけど。

454:nobodyさん
07/07/28 15:02:30
いや、あるあるｗ

455:nobodyさん
07/07/31 03:39:25
俺俺フレームワーク作ってるが
複数DBの抽象化面倒くせえええ
取得できるカラム情報のデータ形式がDBによってかなり違うし

456:nobodyさん
07/07/31 09:11:20
>>455
DBのアダプタみたいな面白くない割に大変で
クリティカルな部分はライブラリ使った方が楽だぜ
俺もO/Rマッパは自分で書いてるけど
DBの抽象化はZend_Db_Adapterでやってる

457:nobodyさん
07/07/31 14:24:55
>>456
ZFはいまいちな印象があったんだが
そんなのがあったのかー
見てみるわ。ありがとう。

458:nobodyさん
07/08/03 00:36:40
>>455
URLﾘﾝｸ(journal.mycom.co.jp)
PHP版Ruby on Rails? - DB操作クラスを自動生成する"PHP Object Generator

こんなので手間を省けませんか？

459:nobodyさん
07/08/03 00:54:56
>>458
結構良さそうだね
既に100万オブジェクト以上発行してるのか
てか字ちっさ！

460:nobodyさん
07/08/03 00:56:38
PHP版Ruby on Railsっていう呼び方は全然違くない？
ジャンルが違う感じだ

461:nobodyさん
07/08/03 00:58:26
なんかもうちょっとでもrailsと被ってたら
タイトルにrailsって書いとけみたいなノリで書いてるな

462:nobodyさん
07/08/03 01:01:07
たしかにｗ

463:nobodyさん
07/08/03 01:26:34
そのうち「生鮮食品版 rails！？」とかもう何でもrails付けときゃ売れるだろ的な

しかしまぁDBの抽象化だのDAOだのってのは
それこそもういっそ言語仕様に取り込んじゃってくれよって話だなぁ……

464:nobodyさん
07/08/03 02:50:28
URLﾘﾝｸ(www.tsujita.jp)ベンチマーク

code igniter以外遅すぎｗｗｗ

　　　　　　ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
　　　　　　＼　CodeIgniter以外ｵﾜﾀｰｵﾜｵｵﾜｵﾜﾀ／
　　　　　　　　　♪＼(^o^)　♪
　　　　　　　　　＿　 ) 　> ＿ｷｭｯｷｭ♪
　　　　　　　　／.◎。／◎｡／|
　＼(^o^)／.|￣￣￣￣￣|　 | 　＼(^o^)／
　　　 )　 )　 .|　　　　　　　|／　　　ノ　ノ
((((　 >￣ > ))))　＼(^o^)／　(((　<￣<　))))
　　　　　　　　　　　 )　　)
　　　　　　　　　(((　　>￣ > ))))

465:nobodyさん
07/08/03 06:23:12
>>458
The BSD Licenseって…
普通ライセンスに"The"なんて付けないだろ

466:nobodyさん
07/08/03 09:53:47
>>465
釣りネタを探す目の付け所は悪くないが表現がやや幼稚すぎる
さらなる精進を望む

467:nobodyさん
07/08/03 09:58:12
表現の問題でなくて、Theをつけないと思ってる頭が幼稚

468:nobodyさん
07/08/03 10:07:16
日本語を話してるのにtheとかつけたら
The PHP frameworkみたいな滑稽さになるね

469:nobodyさん
07/08/03 11:10:03
へーPHP frameworkって固有名詞なんだ

470:nobodyさん
07/08/03 11:17:57
新しいバンドの名前

471:nobodyさん
07/08/03 11:20:35
なぜPHP frameworkが固有名詞？

472:nobodyさん
07/08/03 12:42:33
冠詞(The)を付けるからって勘違いしてんじゃね？

473:nobodyさん
07/08/03 15:03:22
BSD licenseのTheは固有名詞のTheだろ。

474:nobodyさん
07/08/03 15:43:51
Theで固有名詞って、いったいいつの時代の教育を受けたんだ？
固有名詞かどうかなんて考えて話すやつなんていないっつーの。
対象物を知ってるやつ相手ならThe、知らないやつならa、ってだけ。

The PHP frameworkのTheは、PHPはみんな知ってるからついてる。
The BSD licenseもBSDをみんなが知ってるからついてる。

475:nobodyさん
07/08/03 15:54:37
(ﾟдﾟ)ﾎﾟｶｰﾝ

476:nobodyさん
07/08/03 15:56:26
ザ・ガマン

477:nobodyさん
07/08/03 16:13:23
PHP frameworkもBSD licenseも一般名詞であって、固有名詞じゃない。
定冠詞theは、他の一般名詞同様、文脈と英文法に従って付けられる。
しかし日本語で話している時に、そのような文脈的なtheは普通つけない。
「俺、そのフレームワーク知ってる！」という意味で「俺、the framework知ってる！」
なんて言うのは明らかにおかしい。

もちろんThe PHP Frameworkという「名称」のフレームワークを作れば固有名詞にもなるがな。
そうでない限り、日本語の文脈でtheをつけるのはおかしい。

478:nobodyさん
07/08/03 17:03:16
なにをいっているのかわからない

479:nobodyさん
07/08/03 17:17:06
the PHP frameworkもthe BSD licenseもおかしいってことだろ

480:nobodyさん
07/08/03 17:46:39
えーっと
「The BSD Licence」というライセンス名なんだけどー……
「BSD Licence」に the を付けるかどうかなんて話はそもそも無関係なのよ
そもそも英語の名称の話をしてるのに「日本語で話してる時」って前提が既におかしいし

「ビーエスディーライセンス」という日本語名詞の話だと言い張りたいならそれでもいいけど
だとしたら皆と前提が違いすぎて会話になってないのは自分でもわからないかね？

次ページ