- 1 ：nobodyさん：02/04/12 16:42 ID:DpXGWeMS
- ふふ
- 22 ： ◆AngelBlk ：02/04/14 21:37 ID:???
- PHP5の前に、とりあえず4.2・・・。
PHP-devel ML（JP）読んでるけど、
5はかなり大きな変更になりそうだね。 - 23 ：nobodyさん：02/04/14 22:14 ID:???
- >>22
要約キボン - 37 ：nobodyさん：02/04/16 00:52 ID:???
- PHPいいわ。ジャヴァやスィやペルルなんて全くわからないけど
コレは簡単。息子に聞かなくても、もう大丈夫。
これからはPHP,CSS,Flashのトリプルイーズィープログ゛ロマーこそ最強。
わけわかんねーからザヴァとか逝っていいよ。Javascriptは良し。 - 41 ：nobodyさん：02/04/16 22:53 ID:???
- PHPってなんであんなにやり易いんだろう。
Perlとかソースみてると頭が痛くなる。 - 44 ：nobodyさん：02/06/01 23:42 ID:2HMrwkAK
- >>41
PHP で頭痛くならないってたいしたもんだよ。Pear のソースなんて
書き手のオナニーだろ。（あんな使いづらい下手糞な設計でも PHP 標準
でついてきてしまうんだから、参った。） - 50 ：デフォルトの名無しさん：02/06/06 22:27 ID:FSJ1DXvz
- phpでCGIを書けるんですか？
- 121 ：nobodyさん：04/08/20 04:31 ID:???
- PHP5全然使われてないよね。
失敗だったの？
OO廻りがだいぶまともになっていいなあと思ってたんだけど。 - 205 ：nobodyさん：05/02/19 23:48:25 ID:???
- 4から5で大きく変わったか!?
まじでPHPのこと何も知らないだろ。
ttp://www.php.net/manual/ja/faq.migration5.php
Javaもどきなオブジェクト指向だから
既存アプリの移植が面倒なだけで困る低脳はいないだろ。
なんなら互換モードでそのまま動くし。
Perlの4から5、Javaも1.1と1.3、1.4、
VBも.Netへの移行なんかに比べれば
言語仕様の変更は無いに等しいよ。
「基本的なライブラリ」ってPEARのこと言ってる？氏んどけ。 - 211 ：nobodyさん：05/02/20 17:29:17 ID:???
- PHPは、クラス使ってれば動かなくなるんだよね。
特定APIの仕様が変わったというだけのJavaとはレベルが違うよ。
PHPの場合、API的位置付けだったPEAR自体が動かなくなってしまうんだからね。
なんか、PHPの人は必死だな。 - 212 ：nobodyさん：05/02/20 17:57:45 ID:???
- つーか4.0系と4.2以上でかなり違うよね。
マジ使えねぇ。 - 213 ：nobodyさん：05/02/20 20:12:29 ID:???
- 3系から4系、4.0から4.1、4.1から4.2の移行を試みたことがない人なんだろうなぁ。
- 214 ：nobodyさん：05/02/20 22:02:56 ID:???
- >>211
PEAR が API 的位置付け！？はぁ？
それにクラスも機械的変換で動くんですけど。
Pukiwiki とか 4 から 5 対応したアプリのことを知らないの？
>>212-213
具体的にはどこか言える？
まさか global_register じゃないよね？ - 215 ：nobodyさん：05/02/20 22:31:37 ID:???
- >>214
PEARは標準クラスライブラリという触れ込みだったはずだが。
global_registerは影響のない変更ということにしたいわけですね。
使ってるやつが悪いと。ふーん。
4.2.2から、Content-type指定したときの挙動が変わった。
4.3.0から=演算子の挙動が変わったしね。
なんか、必死ですね。 - 216 ：nobodyさん：05/02/20 23:39:53 ID:???
- >>215
いいえ。CPAN 同様、拡張ライブラリです。
ttp://pear.php.net/manual/en/introduction.php
PEAR is short for "PHP Extension and Application Repository"
global_register の問題は PHP3 の時から言われていたことです。一体何年前の話ですか？
使っている奴が悪くないとでも？それに問題を理解しているなら extract(); と書くだけです。
Content-type は php.ini のデフォルトの設定が変っただけでしょう？
= 演算子が === のことを言っているのであれば
まともなコーディングしていれば何の影響もないはずですが？
少なくとも XOOPS、SquirrelMail, phpMyAdmin は PHP4.1.x 時代の
古いバージョンを PHP4.3.x に上げてもそのまま動きますが。
実際問題として >>215 の指摘した内容で変更しないといけないアプリって何かありましたか。
例えば sf.net に挙がっているような奴で。
言語のバージョンアップで仕様変更があるのは当然です。
>>205 にも書きましたが、Perl 4→5、Java1.1,1.3,1.4,VB→VB.NET に
比べれば PHP4 から 5 への変更はないに等しい、と言っているんですが。
PHP5 のクラスは機械的変換でそのまま動くのに何か問題でもあったの？
それに PHP4 互換モードまで用意されているのですが。 - 217 ：nobodyさん：05/02/21 00:10:06 ID:???
- >>216
> Content-type は php.ini のデフォルトの設定が変っただけでしょう？
Content-typeを指定するとエンコーディングの変換が効かなくなったバージョンがある。
ま、古いコードが動かなくなった変更点はそれを使ってるやつが悪いってことにすれば、言語仕様の変更はないに等しいといえることはわかった。
なかなか都合のいい論理展開だな。勉強になったよ。 - 218 ：nobodyさん：05/02/21 00:13:08 ID:???
- global_registerの設定が有効になってるのが前提の情報が広まってた状況を無視して、「使ってたやつが悪い」ですか。
おめでたいやつですね。 - 219 ：nobodyさん：05/02/21 00:15:06 ID:???
- > 少なくとも XOOPS、SquirrelMail, phpMyAdmin は PHP4.1.x 時の
> 古いバージョンを PHP4.3.x に上げてもそのまま動きますが。
そんな例持ち出すなら、Java1.1時代のバイトコードでJ2SE5で動くソフトは普通にたくさんあるわけだが。 - 220 ：nobodyさん：05/02/21 00:17:54 ID:???
- で、PEARが動かなくなったことは問題ではないわけだな。
標準ライブラリ的なプロモーションしておきながら、お荷物になれば標準じゃないですよ、か。
ところで、標準クラスライブラリは何になるの？ - 224 ：nobodyさん：05/02/21 02:14:03 ID:???
- 俺は PHP 使いでもないし PEAR も使ったことがないのでよくわからんが、
Perl が 5.6 から 5.8 になったら CPAN のモジュールが動かなくなった、
みたいなことを想像すると「それはまずいんじゃない?」と思うな… - 225 ：nobodyさん：05/02/21 02:14:34 ID:???
- ＞いいえ。CPAN 同様、拡張ライブラリです。
おいおい、一緒にすんなって。
規模がちげーっつーの。 - 226 ：nobodyさん：05/02/21 02:29:08 ID:???
- >>224
Perl4→Perl5なら動かなくてもかまわないんじゃないの？といいたいのではないかと。 - 227 ：nobodyさん：05/02/21 09:12:58 ID:???
- >>217
それはバグであって仕様変更ではないよね？
また、そのバグは何日で修正されましたか？
>>218
今でも global_register ON がいいの？
あと、普通程度の頭があれば global_register の危険性はすごに分かるよね？
PHP3 の時から危険性が指摘されていたんだよ？何年前の話？
>>219
この例は >>213 の嘘を指摘するためです。
>>220
PEAR のページを見ろよ。>>216 のリンク先とかさ。
標準ライブラリは
ttp://jp.php.net/manual/ja/
でコンパイル・オプションで選ぶだけで最初から組み込まれている奴だよ。
PEAR を使わない/知らないお前が何を問題にしているの？
>>224
Perl4 と Perl5 は？Perl5 と Perl6 は？
ここでの話は PHP4 と PHP5 の話だよ？
>>225
標準か拡張かの話であって規模の話ではないよね？ - 230 ：nobodyさん：05/02/21 15:32:40 ID:???
- >>227
> それはバグであって仕様変更ではないよね？
仕様変更。
日本側からの働きかけで、そのあとtext/*のときはエンコードの指定が効くようになった。 - 234 ：230：05/02/21 15:45:46 ID:???
- ちなみに、content-typeの仕様変更は4.2.2からで、4.2.1で見つかったセキュリティーホールに対策するためのリリース。
そのあとの4.2.3でも日本語関係バグバグ。
で、4.3.0からは=演算子の挙動が変わっている。
つまり、4.2.1のセキュリティーホールを挙動を変えずにふさぐバージョンはリリースされなかったってことだ。
PHPの仕様変更の不安定さというのは、そういうこと。 - 237 ：224：05/02/21 18:51:18 ID:???
- >>226-227
なるほど、確かにそうですね。
Perl4 の時には CPAN なんてなかった (で合ってる?) し、
Perl6 になったら Perl5 との互換性はすっぱり無くなるっぽいし、同じか。
困るってことには変わらないですけど… - 238 ：nobodyさん：05/02/21 19:55:33 ID:???
- >>234
どんな言語でもバグや仕様変更あるので
細かな例を出しても何の意味もないです。
# 例えば Java であれば j-h でセキュリティの未修正や仕様変更で
# 何度も高木氏がポストしたことは古参 Java ユーザなら周知の通り。
それに、過去の例から PHP5.x が不安定である、
という論は無理です。
>>237
Perl4 中盤あたり？から CPAN ありましたよ。 - 239 ：nobodyさん：05/02/21 22:24:16 ID:???
- >>238
バグや仕様変更はあるが、セキュリティーパッチで仕様が変わることは、他の処理系では少ない。
というか、普通はない。
そういう過去の例があるから、PHP5も信用できない。
PHPが信用できないのは、セキュリティーパッチやバグフィックスで他の仕様が変わってきたから。
で、その仕様変更のポリシーが変わったという話は聞かない。 - 240 ：nobodyさん：05/02/22 09:31:43 ID:???
- >>239
その「仕様が変わったセキュリティーパッチ」で動かなくなった有名なアプリって何？ - 245 ：nobodyさん：05/02/22 18:19:49 ID:???
- >>240
なんで、有名アプリである必要があるのかわからんが、EZWeb対応のアプリは動かなくなったはずだ。
ただ、この場合、問題なのは、セキュリティーパッチで他の仕様を変えるというそれ自体がセキュリティーホールであるということだ。 - 246 ：nobodyさん：05/02/22 18:28:32 ID:???
- >>245
捏造情報じゃないことの証明がほしいです。ソースありますか。 - 248 ：nobodyさん：05/02/22 18:46:00 ID:???
- >>245
私は煽りでも何でもなく後学のためにも有名じゃなくていいので
仕様変更によって動かなくなった具体例が知りたいです。
例えば Pukiwiki, XOOPS, phpBB, SquirrelMail, phpMyAdmin,
各種 blog は仕様変更で動かなくなったのですか？
あと、「この場合、問題なのは…」は >>239 とは違う話？
>>239 の仕様変更で動かなくなったものはありますか？
それと >>245 の詳しい話が知りたいです。 - 253 ：nobodyさん：05/02/22 19:05:38 ID:???
- ウチで作ったEZWeb対応のやつは、それで動かなくなったなぁ。
セキュリティーホールってことでアップデートしたら、動かなくなってた。
で、結局元に戻した。
text/hdmlなら日本語変換が動くようになった4.3には他の変更があったから採用見送り。
それ以来、長く動かすシステムをPHPで組むのはやめた。 - 254 ：nobodyさん：05/02/22 19:19:35 ID:???
- 別に自分は有名じゃなくていいですよ。
EZWeb 系が全滅だったら大問題なのに
ML やニュース、2ch の PHP スレで騒がれてないね。
解決策は PHP4.2 に戻すだけなんですか？
>>253
何で作ることにしたんですか？ - 256 ：nobodyさん：05/02/22 20:28:34 ID:???
- >>254
> ML やニュース、2ch の PHP スレで騒がれてないね。
MLを見てないのか？
> 解決策は PHP4.2 に戻すだけなんですか？
コードを変えずに解決するには、セキュリティーホールの影響に注意しつつPHP4.2.1に戻すしかなかった。
設定でどうこうできるものではない。 - 257 ：nobodyさん：05/02/22 21:02:02 ID:???
- >>256
ML 見逃したかも。いつくらいの話題？あとキーワードとか。探してみる。
この問題が知りたい理由は >>248 で書いたアプリを参考に
4.3 でグループウェアもどきを作ったんです。それに影響あるか知りたい。
一体どういう問題なんですか？
不思議なのは >>248 のアプリは 4.3 で問題なく動いてますよね。
あと、4.3 で動いているサーバがほとんどですよね。
なぜ EZWeb 系以外の他の PHP アプリは全滅しないの？ - 258 ：nobodyさん：05/02/22 22:13:13 ID:???
- >>257
4.3で動いてるならいいんじゃねぇの？
4.3ではtext/*はちゃんと日本語変換効くようになったんだし。
> ML 見逃したかも。いつくらいの話題？
しらん。4.2.2が出た頃の話題。
HDML出力してる人はそれほど多くないし、祭りになってるわけではないが。
> 不思議なのは >>248 のアプリは 4.3 で問題なく動いてますよね。
すでに4.3が出てかなりの時間がたってて、なにを不思議がってるのやら。
> なぜ EZWeb 系以外の他の PHP アプリは全滅しないの？
お前、問題の意味全然わかってないだろ。 - 259 ：nobodyさん：05/02/22 23:10:28 ID:???
- >>258
EZWeb のことは指摘通り全然分かってないです。
というかこのスレに書かれた内容では分かりようがないです。
誰かこの件についてのページを紹介してくれませんか？
でも要は EZWeb の件は 2002 年の 4.2.2 の話で 4.2.3 以降では解決済？
1 からこのスレを読んだ限り、PHP の言語仕様が不安定さを示す具体例は
この EZWeb だけです。もしそうなら PHP は他の言語と比べると異常に安定しすぎです。
そんなことはないと思うので、そのほかに PHP の問題があるなら純粋に知りたいです。
PHP が不安定だと主張する人はどの言語を使っているかも知りたいです。 - 260 ：nobodyさん：05/02/23 05:02:30 ID:???
- >>259
は？
セキュリティホールがあったのが4.2.1
content-typeを出力するコード書いたら日本語変換されなくなるのが4.2.2
EZWeb用でHDML吐くときはtext/hdmlを出力する必要があるからEZWeb用は日本語変換されなくなる。
text/*なら日本語変換されるようになったのは4.2.3か4.3.0かわからんがそこらへん。
4.2.3には日本語関係のバグが多い。
言語仕様でいうなら、Javaは1.1と5.0で大幅に変わった以外はほとんど安定で、古いコードの動きがかわらないように注意が払われてるのだが。
で、問題にしてるのは、セキュリティーパッチで仕様が変わったってこと。
セキュリティーホールがみつかっても、バージョンアップできない。
そんな処理系、PHPくらいしかしらない。 - 272 ：nobodyさん：05/02/23 11:36:24 ID:???
- > 99.999999% 大丈夫な仕様変更
これは、日本語対応HDMLのサイトが0.000001％しかなかったってこと？
ま、これこそ根拠レスの煽りだな。
で、=演算子の仕様変更に関してはスルーしてるんだな。 - 273 ：nobodyさん：05/02/23 11:39:53 ID:???
- しかし、PHPの仕様変更の考え方をうまく反映してるよなぁ。
自分のまわりの99.999999%が大丈夫ならいいだろ、みたいな。
日本語使ってるやつなんか自分のまわりに0.000001%もいないから関係ないだろ、みたいなね。 - 274 ：nobodyさん：05/02/23 11:41:54 ID:???
- あと、結果論で、こういうコーディングしてれば大丈夫だったはずだから、そういうコーディングしてるのが悪いってね。
結果論ならなんだっていえるな。 - 275 ：nobodyさん：05/02/23 11:52:42 ID:???
- >>272
EZWeb 以外の実害はなかったからね。
煽れば必死になって他の具体例を挙げてくれるかと思って。
なので数字はお好きな値をどうぞ。
= 演算子で実害が出た実例の件はどうなりましたか？
>>273
269 で書いたけれど 100% 互換を保証している言語はありませんよね。
それついてはどう思いますか？
>>274
結果論の話をしたつもりも、するつもりもありません。
ただ、3 年前にこうだったから、という結果論に
終始していて建設的な話ができないのは残念です。 - 282 ：nobodyさん：05/02/24 05:25:22 ID:???
- >>275
なんでわざわざ実害ださなきゃいけないんだよ。
4.3で=演算子の挙動が変わってるから、バージョンアップすらしない。
動いてるシステムで、実害が出る可能性が高いバージョンアップするわきゃないだろ。 - 320 ：nobodyさん：05/03/13 22:05:30 ID:???
- 318 のドキュメントを読んで
319 の質問をしてくる人に
何て書けば理解してくれるのだろうか - 341 ：nobodyさん：2005/03/29(火) 09:38:01 ID:???
- 別ポートで Apache を起動してる
- 343 ：nobodyさん：2005/03/29(火) 12:37:13 ID:???
- >>341
php.iniはどうしてる
俺はWindowsで再コンパイルがめんどいのでバイナリエディタでファイル名らしき所をph5.iniに無理やり変えてるけど - 523 ：nobodyさん：2005/04/17(日) 17:49:01 ID:T6yAigWO
- そんな事までしなきゃ5って使えないよね、しかも素人が使うフリ―スクリプトには使えない物続出だろうな
- 524 ：nobodyさん：2005/04/17(日) 17:52:07 ID:???
- >>523
素人が使うようなフリースクリプトなんて、ほとんどPHP5でも動くぞ。
何せ、難しい事してないからな。
構造やらソースは物凄くシンプル。
企業で書くような大規模で再利用性を考えたプログラムの方が動かない。 - 566 ：nobodyさん：2005/04/18(月) 12:30:04 ID:???
- phpのいい点は、Cライクで文法を最初からおぼえ直したりすることなく、
すんなりと導入できるところだ。 - 568 ：nobodyさん：2005/04/18(月) 16:01:40 ID:???
- >>566
それを言うなら、PerlもRubyもJavaも、ほとんどCライクっていえる。
PHPは迅速に開発にとりかかれるけど、始まった開発は迅速には進まない。 - 642 ：nobodyさん：2005/04/21(木) 22:09:41 ID:???
- つうか、PHPをCGIで動かすならPHP4とPHP5は共存出来るんだし、
何を問題にしてるんだ？
実際、某鯖ではPHP4とPHP5はどっちでもつかえるしな。 - 644 ：nobodyさん：2005/04/21(木) 22:44:37 ID:???
- >>642
＞つうか、PHPをCGIで動かすならPHP4とPHP5は共存出来るんだし、
＞何を問題にしてるんだ？
PHP5でPHP4のコードのすべてが動くわけではない。
だからPHP5への移行に踏み切れない。それが問題だろ。 - 713 ：nobodyさん：2005/04/24(日) 21:17:12 ID:???
- Javaはいちいちコンパイル＆デプロイするの面倒だしな。
- 714 ：nobodyさん：2005/04/24(日) 22:00:20 ID:???
- 面倒ならAntで自動化すればいいだけじゃない？
まともな開発環境なら、開発時はコンパイルとかデプロイとか意識する必要ないし。 - 717 ：713：2005/04/24(日) 22:21:00 ID:???
- >>714
当然AntもXDocletも使ってるけど、「コンパイルとかデプロイとか意識する必要はない」と
「コンパイルやデプロイが必要ない」ってのは大きな違いですよ。 - 721 ：nobodyさん：2005/04/24(日) 23:50:08 ID:???
- >>717
XDocletはコンパイルやデプロイには関係ないと思うが・・・
で、コンパイルとかデプロイとか意識する必要ないまともな開発環境は使ってるの？
コンパイルやデプロイが必要ないのと大きな違いは無いと思うけど。
デプロイに関しては、開発時にローカルでやる分には基本的に必要ないわけで。 - 785 ：nobodyさん：2005/08/05(金) 19:22:12 ID:???
- エンバグも多いし、change_log読んで
「仕様変更がありました」
って書かれてて問題ないわけない。 - 786 ：nobodyさん：2005/08/05(金) 19:28:57 ID:???
- >>785
考え方の違い。
『仕様変更ありました』と書かれていたら、今現在のシステムなりに影響があるかを考える。
影響があるなら、セキュリティなどの深刻な問題があったかを更に調べ、
特に問題がなかったり、PHPの書き方とかで回避できるのであれば、バージョンアップを見送る。
だから、そんなに問題になる訳が無い。
http://hibari.2ch.net/test/read.cgi/php/1018597325/l50人気ブログランキングへ
