php5これでCGIはphp1色の時代へ
■ このスレッドは過去ログ倉庫に格納されています
>>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 互換モードまで用意されているのですが。 >>216 > Content-type は php.ini のデフォルトの設定が変っただけでしょう? Content-typeを指定するとエンコーディングの変換が効かなくなったバージョンがある。 ま、古いコードが動かなくなった変更点はそれを使ってるやつが悪いってことにすれば、言語仕様の変更はないに等しいといえることはわかった。 なかなか都合のいい論理展開だな。勉強になったよ。 global_registerの設定が有効になってるのが前提の情報が広まってた状況を無視して、「使ってたやつが悪い」ですか。 おめでたいやつですね。 > 少なくとも XOOPS、SquirrelMail, phpMyAdmin は PHP4.1.x 時の > 古いバージョンを PHP4.3.x に上げてもそのまま動きますが。 そんな例持ち出すなら、Java1.1時代のバイトコードでJ2SE5で動くソフトは普通にたくさんあるわけだが。 で、PEARが動かなくなったことは問題ではないわけだな。 標準ライブラリ的なプロモーションしておきながら、お荷物になれば標準じゃないですよ、か。 ところで、標準クラスライブラリは何になるの? ここはどうしてもJava vs PHPに持って行きたいJava厨とPHP厨のすくつですね いや、PHPの仕様変更はたいしたことないといいたいだけ。 推奨されないコーディングをしてPHPの仕様変更にはまるのは、そんなコーディングするのが悪いと。 PEARは拡張ライブラリだから、PHPの仕様変更とは関係ない、と。 俺は PHP 使いでもないし PEAR も使ったことがないのでよくわからんが、 Perl が 5.6 から 5.8 になったら CPAN のモジュールが動かなくなった、 みたいなことを想像すると「それはまずいんじゃない?」と思うな… >いいえ。CPAN 同様、拡張ライブラリです。 おいおい、一緒にすんなって。 規模がちげーっつーの。 >>224 Perl4→Perl5なら動かなくてもかまわないんじゃないの?といいたいのではないかと。 >>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 標準か拡張かの話であって規模の話ではないよね? >>227 すご→すぐ 元々の話は PHP5 はバギーか?だったよね。 でもそれがバギーじゃないことになったので 言語の仕様変更の話になったよね。 バージョンアップして言語使用の変更がなかった言語って何よ? PHP4 と PHP5 の非互換部分は OOP だけど、 言語使用が変わったと騒いでいる奴は PHP4 のままのなんちゃって OOP がよかったの? >>227 > それはバグであって仕様変更ではないよね? 仕様変更。 日本側からの働きかけで、そのあとtext/*のときはエンコードの指定が効くようになった。 あぁ、PEARは、おまけでついてくる標準ではないライブラリってことなのね。 PHP4あたりから標準でついてくるから、てっきり標準ライブラリなのかと思ったよ。 ちなみに、content-typeの仕様変更は4.2.2からで、4.2.1で見つかったセキュリティーホールに対策するためのリリース。 そのあとの4.2.3でも日本語関係バグバグ。 で、4.3.0からは=演算子の挙動が変わっている。 つまり、4.2.1のセキュリティーホールを挙動を変えずにふさぐバージョンはリリースされなかったってことだ。 PHPの仕様変更の不安定さというのは、そういうこと。 > 今でも global_register ON がいいの? そんなこと言ってないだろ。 ってか、global_registersにsがいることくらい、いい加減覚えろ。 >>233-235 で、PHP5 が不安定な根拠は? >>226-227 なるほど、確かにそうですね。 Perl4 の時には CPAN なんてなかった (で合ってる?) し、 Perl6 になったら Perl5 との互換性はすっぱり無くなるっぽいし、同じか。 困るってことには変わらないですけど… >>234 どんな言語でもバグや仕様変更あるので 細かな例を出しても何の意味もないです。 # 例えば Java であれば j-h でセキュリティの未修正や仕様変更で # 何度も高木氏がポストしたことは古参 Java ユーザなら周知の通り。 それに、過去の例から PHP5.x が不安定である、 という論は無理です。 >>237 Perl4 中盤あたり?から CPAN ありましたよ。 >>238 バグや仕様変更はあるが、セキュリティーパッチで仕様が変わることは、他の処理系では少ない。 というか、普通はない。 そういう過去の例があるから、PHP5も信用できない。 PHPが信用できないのは、セキュリティーパッチやバグフィックスで他の仕様が変わってきたから。 で、その仕様変更のポリシーが変わったという話は聞かない。 >>239 その「仕様が変わったセキュリティーパッチ」で動かなくなった有名なアプリって何? >>234 それで動かなくなった有名なアプリって何? >>242 sf.net には PHP アプリが 10430 くらいあるし、 ここのダウンロード数の上位 100 とかでどう? ttp://sourceforge.net/softwaremap/trove_list.php?form_cat=183 >>242 Google でそのアプリ名を検索して 5000 件以上あるとか。 >>240 なんで、有名アプリである必要があるのかわからんが、EZWeb対応のアプリは動かなくなったはずだ。 ただ、この場合、問題なのは、セキュリティーパッチで他の仕様を変えるというそれ自体がセキュリティーホールであるということだ。 >>245 捏造情報じゃないことの証明がほしいです。ソースありますか。 >>246 は? EZWeb用アプリでHDML吐くときtext/hdmlを出力するだろ。 そのとき日本語変換が効かなくなってたんだよ。 >>245 私は煽りでも何でもなく後学のためにも有名じゃなくていいので 仕様変更によって動かなくなった具体例が知りたいです。 例えば Pukiwiki, XOOPS, phpBB, SquirrelMail, phpMyAdmin, 各種 blog は仕様変更で動かなくなったのですか? あと、「この場合、問題なのは…」は >>239 とは違う話? >>239 の仕様変更で動かなくなったものはありますか? それと >>245 の詳しい話が知りたいです。 いま気づいたが >>216 > = 演算子が === のことを言っているのであれば ===は比較演算子だろ。 =演算子でオブジェクトがコピーされていたのが、参照が渡されるだけになったんだよ。 >>247 EZWeb 系のアプリは全滅したんですか? >>248 だから、EZWeb対応の日本語変換が動かなくなってるはずだと。 で、なんで有名ソフトでなきゃいかんの? こんだけ広範囲に影響がある変更が前触れもなしにあれば、PHPでモノ作ってるときに困るんだよ。 PHP用に作られたアプリ動かすだけのやつにはわからんだろうが。 >>250 原理的にはそうだろ。HDML吐いてて日本語変換してるやつは。 ウチで作ったEZWeb対応のやつは、それで動かなくなったなぁ。 セキュリティーホールってことでアップデートしたら、動かなくなってた。 で、結局元に戻した。 text/hdmlなら日本語変換が動くようになった4.3には他の変更があったから採用見送り。 それ以来、長く動かすシステムをPHPで組むのはやめた。 別に自分は有名じゃなくていいですよ。 EZWeb 系が全滅だったら大問題なのに ML やニュース、2ch の PHP スレで騒がれてないね。 解決策は PHP4.2 に戻すだけなんですか? >>253 何で作ることにしたんですか? あと、この問題は >>248 で書いた PHP アプリでは問題ないんですか? この問題の詳細を URL でもいいので教えてくれないですか。 >>254 > ML やニュース、2ch の PHP スレで騒がれてないね。 MLを見てないのか? > 解決策は PHP4.2 に戻すだけなんですか? コードを変えずに解決するには、セキュリティーホールの影響に注意しつつPHP4.2.1に戻すしかなかった。 設定でどうこうできるものではない。 >>256 ML 見逃したかも。いつくらいの話題?あとキーワードとか。探してみる。 この問題が知りたい理由は >>248 で書いたアプリを参考に 4.3 でグループウェアもどきを作ったんです。それに影響あるか知りたい。 一体どういう問題なんですか? 不思議なのは >>248 のアプリは 4.3 で問題なく動いてますよね。 あと、4.3 で動いているサーバがほとんどですよね。 なぜ EZWeb 系以外の他の PHP アプリは全滅しないの? >>257 4.3で動いてるならいいんじゃねぇの? 4.3ではtext/*はちゃんと日本語変換効くようになったんだし。 > ML 見逃したかも。いつくらいの話題? しらん。4.2.2が出た頃の話題。 HDML出力してる人はそれほど多くないし、祭りになってるわけではないが。 > 不思議なのは >>248 のアプリは 4.3 で問題なく動いてますよね。 すでに4.3が出てかなりの時間がたってて、なにを不思議がってるのやら。 > なぜ EZWeb 系以外の他の PHP アプリは全滅しないの? お前、問題の意味全然わかってないだろ。 >>258 EZWeb のことは指摘通り全然分かってないです。 というかこのスレに書かれた内容では分かりようがないです。 誰かこの件についてのページを紹介してくれませんか? でも要は EZWeb の件は 2002 年の 4.2.2 の話で 4.2.3 以降では解決済? 1 からこのスレを読んだ限り、PHP の言語仕様が不安定さを示す具体例は この EZWeb だけです。もしそうなら PHP は他の言語と比べると異常に安定しすぎです。 そんなことはないと思うので、そのほかに PHP の問題があるなら純粋に知りたいです。 PHP が不安定だと主張する人はどの言語を使っているかも知りたいです。 >>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くらいしかしらない。 >>260 99.999999% の PHP アプリは問題なくバージョンアップできましたよね。 しかも text/hdml はコードを変更すれば 4.2.2 に上げることができたよね。 あと、セキュリティーホールが ttp://www.php.net/release_4_2_2.php のことならアップロード部分だけ 4.2.2 にして既存は 4.2.1 にもできましたよね。 PHP が問題であるという主張は 3 年前のその件だけですか? > そんな処理系、PHPくらいしかしらない。 どんな処理系を知っているのでしょう?何と比べて? 少なくとも Java の 1.1.x 〜 1.3.x の x が 1 や 3 の時は Applet に関してはそんなことばかりでしたが。 それを Sun が公開しない、問い合わせ先がないと高木氏がよく報告してましたが。 ttp://java-house.jp/ml/ ただ 1.4 から安定しましたね。PHP も 4.3.x で安定しました。 PHP も Java も過去の事例を元に現行を論じるのは単なる感情論ではないですか? >>260 Tiger との比較は意味がないと思います。 Tiger は C# などを意識して Generic や Autoboxing などの 今更?という改良を加え、マーケティング的な意味でのバージョンアップでしょう。 # 開発環境として PHP5 同様に楽になった Tiger は大歓迎ですが。 違う言語を単純にメジャーバージョンだけで比較するのは無意味ですが、 Perl 4→5 であれば関数の引数でもリファレンス渡しになったり ( jcode とか )、 VB と VB.NET は半分くらい書き直しましたし、 Java 1.3 →1.4 に関しては ttp://java.sun.com/j2se/1.4/ja/compatibility.html とか、PEAR のように JavaBeans/EJB/JBoss などを使っていた場合、 1.3 から 1.4 の移行は PEAR の移行より遥かに大変じゃないですか? そのため 1.4 に移行できない 1.3 のプロジェクトって結構ありますよね? 私は以上の比較で PHP4→5 は「面倒」だが他の言語より「難しくない」と思います。 PHP5 の OOP は単純な機械的な変更ですから awk/sed で半自動で変換できました。 PHP4.0.x 〜 PHP4.3.x は 99% 以上が動く互換性もありますよね。 PHP が他の言語に比べて言語仕様が不安定だったり、移行が難しいとは感じません。 ただ、私は COBOL や VC/C# には詳しくないのでその比較はできません。 # C# は .Net 2.0 が出たら移行に大変そうなので手を出していません。 >>261 > Applet に関してはそんなことばかりでしたが。 言語仕様の話をしてるのではないのか? で、Appletに関しては、Microsoftの実装がJavaの仕様から外れてたからだ。 4.0.6でいきなりPostgreSQLがうまく動かなかったりしたなぁ・・・ なんか、PHPではうまく動く事例だけを扱って、うまく動かない事例は例外ってことにして、Javaではうまく動かない事例をとりあげてうまく動く事例は例外のようにしてるとしか思えないな。 4.3から=演算子みたいな、基本的なところの動きが変わってるのに > PHP4.0.x 〜 PHP4.3.x は 99% 以上が動く互換性もありますよね。 とか、ようゆうわ、って感じだし。 > # C# は .Net 2.0 が出たら移行に大変そうなので手を出していません。 それと同じ理由で、PHP5はPHP5.1が出たら移行に大変そうなので手を出していません。 261 > しかも text/hdml はコードを変更すれば 4.2.2 に上げることができたよね。 どんな変更するかわかってんのか? そりゃ、コードさえ変更すればどんなアップグレードにも対応可能だ。 手間がかかりすぎるので4.2.1のままにした。 そういうアプリケーションの全体に影響するような仕様変更が、一番低いバージョンがあがったときになんの前触れもなく行われることを不安定だっていってる。 セキュリティーアップデートで仕様変更されることが信用できないと言ってる。 >>263 ん? >>260 氏も | セキュリティーパッチで仕様が変わったってこと。 | セキュリティーホールがみつかっても、バージョンアップできない。 | そんな処理系、PHPくらいしかしらない。 であって言語仕様じゃないよね? なのでセキュリティーパッチ云々の Java の例を出しただけです。 それと言語仕様の話って出てないと思うけど言語仕様の話って何?PHP5 の OOP の話? >>264 | Javaではうまく動かない事例をとりあげてうまく動く事例は例外のようにしてるとしか思えないな。 それは >>260 などの主張も同じことだよね。 なので細かな事例を言い合っても仕方ないですね。 Java は言語仕様が大きい分、非互換やバグやセキュリティーホールは PHP より多いし。 自分は Java がメインだし、PHP も使う案件が増えてきたので 客観的な PHP の言語仕様の話をしたいです。なので具体例があれば挙げてください。 | > PHP4.0.x 〜 PHP4.3.x は 99% 以上が動く互換性もありますよね。 | とか、ようゆうわ、って感じだし。 この 99% が間違いであるなら、その訂正は動かない例をいくつか出すだけで済みますよね。 具体例を希望します。そうでなければただの煽りです。 >>265 ですね。今は新規開発ではなく保守の仕事が多いので退屈なので現実逃避中。 >>267 どんな変更が必要かは貴君のソースを見なければ具体的にはなんとも言えないのだけど、 一般論で言えば全ファイルが一番最初に共通の処理を実行する仕組みなら簡単だったよね? 「前触れもなく」に関しては本家 php-dev でも議論になってたし、 小泉さんが日本の php-dev でもこの問題はリリース前に流してたよね? あと、その仕様変更は 99.999999% の PHP アプリには問題ないよね。 セキュリティアップデートに限らず、どんなマイナーなバージョンアップでも 100% 完全互換を保証する言語はないよね? それに、PHP の問題が 4.2.2 だけを指しているなら Java/Perl/VB に比べると遥かに信用できるのですが。 また、その仕様変更が嫌なら 4.2.2 の PHP のソースに 「十数行」のパッチで互換が確保できたと記憶してるし。 >>266 5.0.x → 5.1 の変更点の何を問題にしている?具体的に。根拠レスの煽り? 267 氏が 99.999999% 大丈夫な仕様変更にはまってしまったのはご愁傷様です。 そして 3 年前に解決済みのその一点だけにおいて現在の PHP も信用できないと 評価することも尊重いたします。 でも、もうそのネタはループしてるし飽きたので、 「この言語仕様が PHP は糞」という新ネタをください。 > 99.999999% 大丈夫な仕様変更 これは、日本語対応HDMLのサイトが0.000001%しかなかったってこと? ま、これこそ根拠レスの煽りだな。 で、=演算子の仕様変更に関してはスルーしてるんだな。 しかし、PHPの仕様変更の考え方をうまく反映してるよなぁ。 自分のまわりの99.999999%が大丈夫ならいいだろ、みたいな。 日本語使ってるやつなんか自分のまわりに0.000001%もいないから関係ないだろ、みたいなね。 あと、結果論で、こういうコーディングしてれば大丈夫だったはずだから、そういうコーディングしてるのが悪いってね。 結果論ならなんだっていえるな。 >>272 EZWeb 以外の実害はなかったからね。 煽れば必死になって他の具体例を挙げてくれるかと思って。 なので数字はお好きな値をどうぞ。 = 演算子で実害が出た実例の件はどうなりましたか? >>273 269 で書いたけれど 100% 互換を保証している言語はありませんよね。 それついてはどう思いますか? >>274 結果論の話をしたつもりも、するつもりもありません。 ただ、3 年前にこうだったから、という結果論に 終始していて建設的な話ができないのは残念です。 >>273 EZWeb 業界における PHP の普及率でどうなの? それによって数値が算出できると思うけど。 >>272 世界的に見た場合の EZWeb だとそれくらいじゃない? つーか、なんで糞 PHP を使っといて文句言ってるの?自己責任じゃない? 自分の技術力のなさを PHP のせいにしているだけだろ。 >>267 「前触れ」はML以外にもRCで出てただろ >>267 「手間がかかりすぎるので4.2.1のままにした。」という 三流プログラマー自慢の意図はなんですか?一体どんな手間が掛かるの? 俺今PHPを使った仕事をしてるけど、ちょっとバージョン返ると すぐ挙動が不審になる。駄目だPHP超使えねぇ。 頭のおかしな人には気をつけましょう ttp://info.2ch.net/before.html >>275 なんでわざわざ実害ださなきゃいけないんだよ。 4.3で=演算子の挙動が変わってるから、バージョンアップすらしない。 動いてるシステムで、実害が出る可能性が高いバージョンアップするわきゃないだろ。 スゲェ 今度は試しもせずに妄想で責めてきたよ 引き篭もってないで外の世界を見れば 下の中以上のプログラマのプログラムなら動くことが分かるのに まぁ、下の下、頭のおかしなプログラマには無理なわけだが だから100%完全保証を主張してるのか >>282 4日前の >>215 も具体例も試しもせずに=演算子が,と書いていたの!? いったいそれで何の話がしたいの or できるの? global_registersやezの件とか頭悪いなぁ,と思ってたけど 頭が悪いんじゃなくて頭がおかしいんですね. PHPでの環境なんてまだほったて小屋みたいなもんだから、 具体例とか、実害とか、実例とか99.9パーセントとか言うな。 適当に最適なコード書いとけ。ハゲ! >>284 具体例って、仕様が変わってて明らかに影響があるんだから、移行しなかっただけ。 なんで、実害あるのわかってて試さにゃならんのだ? >>288 286-287 によると 具体例とか、実害とか、実例とかないけど PHP はダメだそうです。 あと、バージョン上がっても 99.9 パーセントが何の問題もなく動くけど PHP はダメだそうです。 PHPがダメとは言ってないだろ? (try{}catch{}も5でやっとこさできるようになったようなヘタレ言語だがな!) おまいが「PHPってダメなの?」思ってるだけなんじゃなくて? このインポ! >>290 | PHPがダメとは言ってないだろ? そうだったんですか。じゃ、どういう主張だったのですか? |(try{}catch{}も5でやっとこさできるようになったようなヘタレ言語だがな!) Autoboxing や Generic も 5 でやっとこさできるようになったようなヘタレ言語だがな! というようなことを言うことに何か意味がありますか? 善いことをするのに遅いと責める気はありません。 善いことをしないのであれば催促したいですが。 | おまいが「PHPってダメなの?」思ってるだけなんじゃなくて? そうです。C/Java/VB/Perl の比較において PHP が特別にダメとは思えません。 ダメな点はありますが、それはどの言語でも同じことです。 | このインポ! 頭のおかしな人には気をつけましょう ttp://info.2ch.net/before.html | 根拠もなく、他人を卑下したり、差別したりする人、自分で自分を褒める人 なんだよなんだよ、言葉尻ばかりつかまえて。 いじめてるつもりはないが、2ちゃんなんだし罵り合い上等でしょ。 別におまいの自尊心=PHPってわけでもねーだろ。 おまいも99.9パーセント動くけど(もじもじ・・・)とかさあ、うざいよ、 なんの分母の99.9だよ。たいした評価じゃあなかろうに。 それにしてもPHPは事実人気もあることだし、 より良いオブジェクト指向、フレームワークの充実、と 良いところはたくさんあるんだから、がんばってほしいと思うよ。 RubyやJAVAを参考にしながらOOを整理していってほしいし、 かつ、ライトウェイトっつー身軽なところを伸ばしていって欲しい。 ってかたっちまった。当たり前なことを。野暮ったいね。 99.9% は地球上の全 PHP アプリのことね。 「もじもじうぜぇよ」ともじもじしないで不明なことは聞くように。 あと、もし 99.9% に突っ込みたいなら 「99.9% は言い過ぎだろ、デブ」だけの根拠なしではなく、 「○○で××だから98.7%だろ」という論理的反証でよろしく。 後半はハゲ同。建設的でいいね。 一番好きな言語は Ruby。素晴らしい OOP だ。 一番嫌いなのは一番使っているせいか Java。 203 からのを読むとこんな程度で騒ぐなよ、という感じ。 >>293 ワロス。 やっぱRubyはいいよな。 オタとか言われてるけど、んなこたぁーないぞ。 あれに学んだ人のPHPのコードは素敵そうだもの。 Ruby も Rite で RAA 全滅するけど 妥当な変更による結果なので文句を言う気はない。 PHP4 → 5 で PEAR が動かなくなるのも同様。 PHP4 の OOP は Perl 同様ありえない。 まぁ、非 OOP の互換性を保ちつつ OOP の皮をかぶせるためには仕方ないのだが。 PHP5 の OOP 化は Java を手本としているので冗長で退屈。 Ruby のようにスッキリ書けると嬉しいのに。 あと ; が不要になるともっと嬉しい。 つーかお前等なんでそんなにPHPに固執してんの? まるでPHPしかできないみたいな必死さだな。 PHPしかできないんじゃプログラマとして将来期待薄だな。 せめてJavaとかPerlくらいは理解しとけよ。 おまえらはどれだけデザインパターンを理解して・・・ スレが立ってからもうじき3年だけど、3年で何が変わった? perlやrubyのcgiはなくなったか? インターネッツできない場所にでも幽閉されてた人ですか 普通にまだ多いと思うが。少なくとも日本で"配布されている"WebアプリではまだPerlが一番多いだろうな。 使用されている物については同じかまだPHPの方が少ないぐらいかな? 海外だとPHPの方が抜いてるみたいだけど中国韓国ではASPだんとつ、他ではJSPやPHPって感じだったかな。 まぁ、数値の取り扱いが仕様で決まってないPHPで、数値の計算をまともにやろうとするな、ってことだな。 PEARのPHP5対応率って低い? 先を見越してPHP5で何か作ろうと思うんだけど。 >>307 人気のある PEAR は大丈夫。 自分が何の PEAR を使うか確認してみては。 >>309 レスサンクス PEARが対応してるならOKだね。 PHP5 で問題なく使えるよ。PHP4.0.6 以降に対応。 PHP5をインストールするとSQLiteも自動的にインストールされますか? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる