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

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

251 = :

5.2みたいにパフォーマンスが上がったわけじなくて
変な文法増えただけだろ？
ｲﾗﾈ

252 = :

そんな餌に釣られるもんですかっ

253 = :

バックスラッシュな時点で日本ではオワタな感じがする。

255 = :

どこに割り当てればよかったと思う？

256 = :

考えなしに記号を消費しまくったPHPが悪い。

257 = :

PHPはそう遠くないうちに終わるだろう

259 = :

PHPが何に取って代わるの？

260 = :

>>259
何がPHPに取って代わるの？

じゃなくて？
今のところPHPに変わるものは無い気がするけど。

rubyやpythonはちょっと違う気がするし。

261 :

>>251
そうなんだ。
GCの改良ってあったけど、パフォーマンスにはそんなに効かないのかな。

ディストリが採用するまで待つか。

262 = :

PHP最強ということFAですね

263 = :

強さは知らんが、PHPのポジションはそれなりに気づいてると思うけどな

264 = :

言語記法としてはウンコ。
標準機能(extension含む)の手軽さではピカイチ。

言語としては ECMAScript が手軽かつ綺麗なのでいつか主流になると思う。
サーバサイド実装がほとんど無い現状だけども。

265 = :

あんだけ普及してたPerlもいまじゃPHPと入れ替わったわけだし
いつかまた別のが来てもおかしくはないとは思うけど
当分はPHPが死ぬことはないと思うなー

まぁ入れ替わるとしても、風向きが変わってからとりかかりゃいいしな
なんだかんだで今後もあまり発展性のなさそうなものを新たに覚えるよりは
いま使いやすいのを使っておくのが無難かなと思うトコロ

266 = :

PHPは当分残るだろうね。
良くも悪くも現状のWEB開発においては不満が少ないし、十二分に枯れている。

ブラウザとの親和性も含めるとECMAScriptがなんらかのきっかけで爆発的に普及する気がしないでもない。

268 = :

Rhino on Railsかね、JSの本命は。
あれが来たらもしかしたら意外とサーバーサイドJS流行る可能性があるかもしれない。
webやるならいずれにせよ多少は触る言語だしね。

269 = :

Rubyは導火線だったけど、爆発物じゃない、みたいな感

271 = :

PHPは爆発物では無い、もはや炭みたいなもの。

272 = :

練炭ですね

273 = :

炭はむしろほめ言葉だけどなｗ

274 = :

褒めてるんだよｗ

ここまで手軽で高機能で普及していて枯れているWEB系言語は他に無い。

275 = :

ガラッと変わってもいいから1度ちゃんと整理してほしいなあｗ

277 = :

便利にするには無駄に消費してしまった文字を使った
過去互換機能を切る必要があるからなぁ
ごっそり削ってほしいところがいっぱいあるんだけど、難しいんだろうなぁ

278 = :

過去互換機能を残しても無くしても叩かれるんだからかわいそうね

279 = :

引数の型指定に、stringとかが指定出来ないのが納得いかねぇんだよぉおおお･･･

設計した奴はまじでウンコ。

281 = :

280みたいな人が多いから、PHP使いは見下されるんだよな･･･

厳密な型指定が出来るに越した事は無い。

282 = :

お前は何を言ってるんだ
じゃPHPでない言語使えよ

283 = :

>>281
型指定を理解できないと情けないかもしれないが。
型指定を理解して使わないなら問題無いじゃん。

284 = :

コンパイル言語なら必要

285 = :

何故関係無いことを持ち出すのか分かりません

287 = :

型指定ができないせいで、かえって型を意識しないといけない、という局面は結構多いと思う。
case 0:とかな。
メリットは大きいが、全体を通してみるとデメリットの方が大きいと思う。

>284
問題はコンパイル言語かどうかじゃない。静的型言語か動的型言語かが問題。

288 = :

PHPの場合は自動型変換がウンコだからデメリットの方がでかい

289 = :

>>283
>>280が型指定を理解してるとは思えないがｗ

型指定の「強制」はPHP的にありえないには同意。

>>279は引数の型チェックとして型指定が出来るようになったのに、
なぜstringやintが指定できねーんだ･･･糞が！！って事を言いたかった。
だから中途半端で、頭悪そうな言語になっちゃうんだよ！

290 = :

型指定が必要になるような規模のコードはPHPで書かないから問題ない

291 = :

PHPってめちゃくちゃパーサーがしょぼいよな。print "$var全角"とかで平気でパースエラーが起きる。$varが展開されない。

293 = :

if とか while とかでブロックのネストが深いところでシンタックスエラー起きると、エラー発生の行数が出ない事もある。

294 = :

>>291
それをパースエラーと言わない。
たしかPHP4時代からのFAQだよね。

295 = :

行数じゃなくて行番号だった

297 = :

多分機能詰め込みすぎたピザメソドでも書いてんだろう

298 = :

閉じ中括弧"}"忘れとかw

>>291=>>293 かな?
今時、print "$var全角" とか、深いネストとか。
大丈夫?

299 = :

PHPだって普通は行番号出る。そんなの他の言語でも当たり前。ところが、コードが複雑になってくると、エラーメッセージから行番号が消えて、どこかにエラーがありますって。どういう理屈なのか知らない。

300 = :

型指定の問題もこういう絶望的な。
http://d.hatena.ne.jp/JULY/20090622/p1

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [98%] - 2008/8/24 19:04 ○
• 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [98%] - 2008/12/23 16:48 ○
• 【PHP】フレームワークについて語るスレ12【総合】 (994) - [98%] - 2009/3/19 13:46 ○
• 【PHP】フレームワーク CakePHP　3ホール目【本命】 (1001) - [59%] - 2008/6/19 7:19 ○
• 【PHP】セッションについて語ろう！【PHP】 (829) - [58%] - 2018/6/27 23:16 ○
• 【PHP】フレームワーク CakePHP　4ホール目【v1.2】 (1001) - [57%] - 2008/12/19 21:06 ○
• 【PHP】フレームワーク CakePHP　6ホール目【v1.2】 (933) - [57%] - 2009/8/19 2:06 ○
• 【PHP】フレームワーク CakePHP　5ホール目【v1.2】 (985) - [57%] - 2009/3/7 4:53 ☆
• 【PHP】フレームワーク CakePHP　7ホール目【v1.2】 (1001) - [57%] - 2010/3/18 1:18 ○