>>32282
そんな迷惑なもん考えるヒマがあるならさっさと寝ろ

素人ですｗ

>>32283
何のためにトランザクションがあるのかと
小一時間(ry

>>253
んなことMLに書いたら、トランザクションってなんですか？と小一時間質問が...

>> 32286
突っ込みどころはそこじゃない希ガスｗｗｗ

リレーション張れてないよな

プルグラム

なんか日本語おかしいと思ったら、日本人じゃなさそうだね。

>>258
内容のおかしさに比べれば日本語のおかしさは我慢できる。

>>259
つか、32283=32232

32289
また食いつきの良さそうなネタだこと

Zend使ってないからいいや

ファイルの最後の?>を取るのはsymfony辺りでも推奨されてたような。
文字コードがUTF-8N以外だと、requireしたファイルの最終行にあった改行がheader()とか
session()系の動作を怪しくするからね。

普通取らないだろ...

＞Apacheの方が大きいという事になるのでしょうか。

これ、理解できてないなら使っちゃﾀﾞﾒだよ

>>32301

釣りかとｵﾓﾀｗｗｗ

ありがたいシチュエーションが非常に限定されていると思うが。というか見つからない。

.htaccessさえ設置できない切ない環境で、意味もわからずループで$_POST,$_GET,$_COOKIEにstripslashesをかけ（させ）て、PHPの本当にありがたい、フォームで配列が使えるていう機能をスポイルするだけの、初心者（およびその教育者）泣かせの機能にしか思えんのだが。

そこで再帰で配列の底までstripslashesをかけるようなプログラマは、正直PHPが大嫌いだと思う。
そういう人はまず間違いなく、DBアクセスにはRDBMSのプリペアドステートメント（もしくはそのエミュレータ）を使うだろうし、表示する変数値には（文字列、数値関係なく）"表示の際に"htmlspecialcharsをかけるだろうし。

結局、誰のためにもならない機能だとマジレスしてみる。

マジッククォートとか<?=$var?>というのは、PHPの長所だよ。これを廃止したら、PHPのメリットは大きく損なわれて、他の言語に取って代わられるだろう。
例えば$_REQUESTを配列（ハッシュ）ではなくオブジェクトにすることも出来るだろうが、それはPHPの用途、ユーザ層には合わない。

>>271
マジッククォートが役に立つ場面をマジ教えて。
百害あって一利なしだと思うぞ。

そういう物だと思って使えば便利だろ。
それより3項演算子が左結合とか、未定義の定数を文字通りの文字列で評価するとか、そっちの方がよっぽどわけわからんね。

マジッククォートも3項演算子が左結合も未定義の定数も
例えそういう物だと思ってても便利に使いようがないって点じゃ似たり寄ったりだ

百害のうちの一利を考えた。
DB接続が「ウリ」だったphp3時代のSQL文に使うエスケープ処理といえば、
addslashesだった。それと同等な処理がmagic_quotes_gpc = on
これで初歩的なSQLインジェクション対策にはなる。

デフォでOnというのも、サニタイジングの観点からすれば正解で、
入力にしろ出力にしろ、「必要なときにエスケープ処理をする」と考えると抜けが出るので、
「必要でないときに回避させる」としていれば、不用意に穴が開いてしまうということは
低減される。

>入力にしろ出力にしろ、「必要なときにエスケープ処理をする」と考えると抜けが出るので、

addslashes だけかかっていても屁の役にも立ちませんが。htmlspecialcharsとpreg_quoteとurlencodeとその他あるだけ全部かけて、必要じゃないのをとってやれと？
どう考えても実用的にも原理的にも、「必要なときに、必要なだけ」だろう。それでは「一利」とはいえないんじゃ？
まあ本気じゃないとわかってはいるが。

>>279
あくまで「百害のうちの一利」と理解されていると思うが、サニタイジングについて。

マジッククォートは一利(すらない)に伴う弊害がでかすぎなので、流石にOffにしているけど、
パラメータクエリでエスケープされるのが基本。
出力はテンプレートエンジンSmartyのassignは全てhtmlspecialcharsを通すようにしてる。
urlencodeやpreg_quoteは必要なときだけだけどね。

PHPの3項演算子は他の言語のそれと違って、条件式を複数書けないアホ仕様。オンオフ切り替えられるマジッククォートとはまるで違う。

カッコ使うだけで普通に複数書けるわけだが

読みやすくするために3項演算子使うのにカッコだらけになるくらいなら、素直にifを使った方がマシ。こんな仕様、PHPだけだろ。

>>284
その前に、入れ子になった3項演算子を使うならifの方がマシってならね?
で、1重程度の入れ子ならカッコを使った方が、ハッキリしてて読みやすいし。

言語を作ってみるとわかるが、３項演算子の実装は、一番むずかしい。
それでも、いくつかの言語の実装を見ればわかる。
つまり、PHPの開発者は、３項演算子を実装する実力もないってことだ。

他の言語とPHPで具体的にどう違うの？

>>287
どう違うというより、使ってみれば直感的におかしいと思うんじゃね。

true ? true ? 1 : 2 : 3 ; // 1が返る。
false? true ? 1 : 2 : 3 ; // 3が返る。
true ? 1 : true ? 2 : 3 ; // 2が返る。他言語は1。
true ? 0 : true ? 2 : 3 ; // 3が返る。他言語は0。

俺の場合は他言語であってもカッコを使うがなぁ。
なので、PHPの3項演算子がおかしいとは普段感じない。

三項演算子だのPHPだのに限らず、
ちょっと誤解される可能性のある式には惜しみなくカッコを使うようにおれはしてるけど、
こういうところをケチって書く人のソースは大抵ちょっとした仕様変更にいちいち弱い。
だからそういう人はPHP自体への印象も悪いんだろうな。

>>286がどういう言語をどういう風に作ったのかぜひ聞いてみたいものだ。
おれが昔自作のログリーダに簡易言語を乗せた時には、特に難点はなかったが。

>>288
下２つは普通に考えて１と０だと思うが
なんでPHPはそんな仕様になってるの？
つかどうパースしてんだろう？

>>289
a > 0 && a < 10 ? "1-9" : "対象外"
というの、書けた？
論理演算子の優先順位に工夫が必要だった。

>>290
( true ? 1 : true ) ? 2 : 3 ; → ( 1 ) ? 2 : 3 // 2が返る。他言語は1。
( true ? 0 : true ) ? 2 : 3 ; → ( 0 ) ? 2 : 3 // 3が返る。他言語は0。

カッコなくて済めば楽なように思えるけど
おれは他言語でも上のようにカッコ使うようにしてるなぁ
そもそもこんな解りにくさを誘発する多重三項は使わないようにするけどさー

>>291
三項演算子ならBNFに落とせる範囲内だからyaccとか使えば難しくはないんじゃないかな
おれの自作はyaccとか使えない環境だったんでトークン分け＆構文解析も自作だった……

なるほど
( true ? 1 : true ) ? 2 : 3 ;
true ? 1 ( true ? 2 : 3 ) ;
この2つの違いか
そう言われてみれば前者でもおかしくはない気がしてきたが

>>292
そう。適当にやってればはまるんだけど、まあすぐにできる範囲。
PHPは、適当にやってハマってそのままな感じ。

ヲチスレで議論はﾔﾒﾚ

>>295
MLが農閑期に入ったからね。しゃあないぶぶんもあるよ。

>>297
勝手にお世話にならないで下さい。
お世話するかどうかはこちらが決めます。

32321
ネットから隔離するのはいいが、原因を究明せずに再インストールしても時間を無駄にするだけだとオモ。