【PHP】下らねぇ質問はここに書き込みやがれ 12

[過去ﾛｸﾞ] 【PHP】下らねぇ質問はここに書き込みやがれ 12 (1002ﾚｽ)
上下前次 1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

712: デフォルトの名無しさん (ﾜｯﾁｮｲ c17b-NIVl) [sage] 2021/08/06(金) 20:51:49.77 ID:lgptz/Bq0

> Content-Length
おお正解出てきたか。実はこちらもそこに気づいて試して(昼間に)確認済みだった。
んで、いちいち文句言われるからとりあえず夜まで待ってたところだった。

つかマジで、お前らだいぶ酷いわ。改めてPHPerは糞だと再認識した。
小学生同士の小手先テクニック大会は楽しいのだろうけど、そんなんだから上達しないんだと思うぞ。

>>710-711
こちらはheaderだけで問題なくなった。
とりあえずサイト読んでみたが、こちらの結果からすると、ob_xxxもconnection:closeも要らんね。
(というか多分 connection: close は問題になるからやらない方がいい）

> そもそも後処理とやらを軽くすればいい話ではないのかね
> DBの設計とSQLの書き方次第で速度がかなり違うよ
> そこを見直すのがいいんじゃないかな
勿論分かってるが、今でも十分軽いし、これ以上どうしようもないので。

> 接続の管理はできないのでは無いんでないのかね
これは違う。接続の管理を「しなくてもいい」のであって、「出来てもよい」んだよ。
単純には機能が足りてないだけ。
近いのはGUIのイベント、onXXXだが、
あれも最初は addEventListenerとかは不要(onXXXだけで問題ない）と思われてたんだよ。
でも、有るのと無いのとでは大違いで、今は全面的に採用されてるだろ。
といってもお前らは若すぎてこの話が意味不明なら、イベントバブルでもいい。
あれもHTMLは最初から搭載していたようだが、おまえらPHPerなら特に、バブルなんて無くても設計出来ると思ってるだろ？
しかしこれも同様に有るのと無いのでは設計のしやすさの次元が違ってくるので、全面採用になりつつある。
機能が足りてないときでも、足りてないと気づけない人の方が多い。
ネットが無くても不自由しなかったし、その前は携帯が無くても不自由しなかった。
無ければ無いなりにやってしまうものなのだけど、これが有ればどんなに良いか！と思いつける人はほぼ居ないんだよ。
(一応言っておくが、俺も思いついたわけではなく、他言語で知ってたから不便を感じられただけ)
例えば、asyncとか、技術的には最初からあっても不思議ではなかったけど、誰も思いつけなかったろ。あれと同じ。

http://mevius.5ch.net/test/read.cgi/tech/1619667579/712

716: デフォルトの名無しさん (ﾜｯﾁｮｲ c17b-NIVl) [sage] 2021/08/06(金) 22:36:18.90 ID:lgptz/Bq0

>>714
すまん、前後した。手間をかけて本当にすまん。

> node.jsはwebサーバーを内包しているから出来ることでphpはwebサーバーを内包していない
これはその通りだが、PHPから出力をクローズしたら当然apacheにも伝わりクローズされる。
そしてこれはnodeでも同じだ。
実際は(Nodeでも)closeしてもhttpコネクションを切っているわけではない。
それだと再送要求が来た時に対応出来ないだろ。
だから、実際の低レベルの接続はNodeでもPHPでも同様に隠蔽されてる。
(勿論ApacheはHTTP/1.1だとgzipしてるし、別にバッファも持ってる)
よって、PHPでもNodeと同様に『プログラミングモデルとしては』接続を切ることが出来る。
だからやっぱり機能が足りてないんだよ。

パイプで説明した方が分かりやすいかな？
php | apache > /dev/eth0 な状況で、php が stdout（出力パイプ） をクローズすることは出来るだろ。それだけ。
その後も apache は必要なら動き続けるし、終了すれば終わる。
この構造はNodeも内部的に持ってないと話にならないから同様の筈だよ。

ただしそもそも論として「Content-Lengthは常に付けとけボケ！」なノリのようだ。
この手のTipsとしてはStackoverflowが秀逸で、
https://stackoverflow.com/questions/2773396/whats-the-content-length-field-in-http-header
の回答の中に以下仕様書へのリンクとかがあるが、
https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
読む限りContent-LengthはもしかしてHTTP/1.0時代には必須だったのかな？

今現在、 echo json_encode(...); でjsonを語れ流してるから、これアウトかよ、、、、ってちょっと萎えてる。
メモリを無駄に食わない素晴らしいコードだと思ってたんだがなあ、、、。

http://mevius.5ch.net/test/read.cgi/tech/1619667579/716

721: デフォルトの名無しさん (ﾜｯﾁｮｲ c17b-NIVl) [sage] 2021/08/07(土) 00:55:28.53 ID:dDF85n970

>>717
ただまあ、これはさておき、
そもそも環境依存コードを導入する気はないが、無料鯖は大体CGIモードだから行けるのか。
とはいえ少し金かけたらモジュールも選べて、
その際にいちいち「動かなくなりました」とか言われるのが面倒だから止めとくが。

ただ、これだとやっぱり昔は必要だと認識されてたって事だよ。
正直、Content-Lengthよりも直接的で分かりやすい解決策だから、俺も606で言ってるように、
最初に整備されるAPIであり、普通のプログラマにとっては第一選択肢の筈なんだよ。
ただこれだと、モジュール化した際に不要だと見なされて落とされたってことになる。これは何でだろう？
実装自体は至極簡単だし、基本的な物だから、「問題を多発させた」とかない限り落とす判断にはならないはずだけど。

> また、Content-Lengthは後処理不要ならば付けなくても問題なし
MDNは「付いている時も、付いてない時もあります」と言い、
W3Cは「出来る限り付けろ。ストリーミング以外は付けられるだろ」と言い、
実際の他サイトは確かに「付いている」ので、ちと迷ってる。

> json出すならContent-Type: application/jsonは付けたほうがいいと思う
これは勿論付けてる。てか、そうじゃないとブラウザで正しく読めないので。

> 楽に使うならクラス作って継承して使えばエレガントに書けると思う
問題はそこではなく、メモリを出来るだけ食わない方法でやろうとしてた。
jsonはDBの読み出し結果から直接生成する（長さを予期出来ない）ので、Content-Lengthを付けるにはob_xxxxを使うしかないが、
これだと単純に倍のメモリを食ってしまうので。
まあ君らは「でも物理で殴る方が速いんでしょ？」なノリで、実際これも事実ではあるが、俺としては以下と同様、
正しく使えばポンコツでも速いぜ！を目指したいんだよ。
https://qiita.com/masarufuruya/items/3bd72326448e4f8fa569
JSがそうなんだけど、おそらくPHPも同様で、糞コードばかり食わされて正当な評価を得ておらず、
それなりに洗練されたコードだったら意外と速いんだろうとは思うよ。
Webでは「速いよりも早い方が重要」だからある程度致し方ないのだとしても。

http://mevius.5ch.net/test/read.cgi/tech/1619667579/721

723: デフォルトの名無しさん (ﾜｯﾁｮｲ c17b-NIVl) [sage] 2021/08/07(土) 09:24:23.62 ID:dDF85n970

>>717
一応こちらの現時点の結論を言っておくと、
Content-Lengthはストリーミング以外は全部つけないと駄目だな。RFCでもSHOULDだし、
https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.2
動きを見る限り、apacheもこれをスヌープしてる。
よって、「仕様準拠」なら flush() だけで何も問題ないから、
fastcgi_finish_requestはモジュール化した際に廃止された、と見える。

だから711内のページ筆者もだいぶ間違ってて、
まずConnection: closeをTCP接続終了（いわゆるFIN/FINACK/ACK)と勘違いしてるが、
実際はこれは同じコネクションを再利用するかの話だから関係ないし、
HTTP/1.1だとデフォでkeep-aliveなので無駄にcloseにするとバグに当たる可能性があるから悪手だ。
https://en.wikipedia.org/wiki/HTTP_persistent_connection#HTTP_1.1
そしてContent-Lengthを付けたら上手く行くよ！ではなく、付けないと話にならなくて、
仕様準拠＝付けてれば最初からこんな事にはならずに済んでる。
だからこいつも俺も『仕様を知っている者から見れば』ただのマッチポンプでしかない。

ここで711内ページ筆者、俺、或いは君らも含めての問題は、レイヤーを間違ってることだ。
PHPは生のヘッダを普通に扱えるレイヤーでのプログラミングになるから、ヘッダについての仕様を(本来は)熟知してないといけない。
だから575に対してはいきなり「Content-Lengthヘッダ付けろ馬鹿タレ」とぶった切れないといけない。
とはいえ昨今の状況であらゆる階層の仕様を熟知しろなんてどだい無理な話ではあるが。

だからやっぱりもう一つレイヤーを上げるべきなんだ。
ヘッダの知識がない状態で具だけ書きたいのなら、ヘッダ周りを自動的によしなにやってくれるフレークワークを使うべきだろう。
そしてLaravelは見たところそんな感じだ。
なるほど、「セッション周りとかはフレームワークに任せてLaravelだけ使ってろ」というのは当たってる。
(俺も含めて）素人ほどフレームワークを使うべきだろう。

とはいえ、俺はデプロイ先が無料サーバなのでいちいち仕様確認して素PHPレイヤでのプログラミングをするしかないのだが。

http://mevius.5ch.net/test/read.cgi/tech/1619667579/723

736: PHPerは糞 (ﾜｯﾁｮｲ c17b-NIVl) [sage] 2021/08/11(水) 21:04:54.72 ID:C/NScrzP0

ここで、直積みコードを動かす為には format_for_API を「参照渡し」から「値渡し値返し」に変更する必要が有り、
コードは、

$resultArr = fetch_from_DB();
$resultArr = format_for_API($resultArr); // 再代入
echo json_encode($resultArr);

となる。これだと結果としては速度/メモリ共に変化無い。ただし最近の『再代入禁止』には反するので、

$resultArr = fetch_from_DB();
$resultArr_formatted = format_for_API($resultArr); // 別名
echo json_encode($resultArr_formatted);

と別名にすると、(今回の俺の場合、速度は大して変わらないが)使用メモリは増えてしまう。
これらから言えるのは、

A. format_for_APIは「参照渡し(参照返し)」が正しいはずだが、何故かNoticeが出されてしまう。
　仕様としては、参照渡しに未初期化の変数が渡されたらそこでnull初期化される、ということだから、
　直積みでも動くのは正しく、Noticeが過剰なように見える。（ただし以下7とは矛盾）
　(PHPの構造上 is_ref が変数上にしか持てないのが問題なのだろうが、
　そこはボックス化みたく変数化すればいいだけで、このような右辺値を流し込んでいる状況なら危険性はないはず。
　実際動いているし。だから何でNoticeなの？となる)
B. 同名の変数に再代入する場合は(破棄されることが見えているから)最適化がかかり、問題はない。
C. 別名の変数に保存した場合、元の変数($resultArr)がそれ以降使われない場合でも、破棄されず、最適化がかからない。
　結果、メモリを余分に消費する。

これについて、冒頭の記事では「そういう特殊な高級言語だ」と表現されているが、これは当たっている。
クダグダ考えずに「値渡し値返し」でひたすら全部組み上げてもそれなりに動くからだ。
そして昨今の『インミュータブル』で『再代入禁止』なのは下位での変更が上位のコードから見えないからであって、
PHPの場合は「値渡し」でガッツリ保護されているから、
『再代入禁止』『参照透過』何それ美味しいの？でも確かにそれなりに問題ないはず。

http://mevius.5ch.net/test/read.cgi/tech/1619667579/736

737: PHPerは糞 (ﾜｯﾁｮｲ c17b-NIVl) [sage] 2021/08/11(水) 21:05:17.28 ID:C/NScrzP0

俺の現環境ではBしか選択肢がないが、ここら辺はPHP界隈ではどうなってるのだ？具体的には、

1. 理想的にはAでNoticeが削除されるべきだが、既にそうなってる/これから削除予定か？
2. (知らんが、)実はPHPって一つのコードで出来てて、「おま環」ってのがあまり無く、
　俺の環境でBが最適化されてれば、どの環境に持って行っても最適化されてて問題なく動くのか？
　（これについてJSが悲惨なのはご存じの通り)
3. まさか、notice切ればいいだけだろ、とか言うノリか？(個別に切れるのならこれも有りだが）
4. 最適化を期待して、参照渡しの使用自体を禁止/抑止する方向か？
　(真に必要な場合以外は使うな等。今回なら上記のように同名の変数に代入すればいいだけだよね、みたいな。）
5. この辺も含めての、文法(見た目)以外のコーディングルールで有名なのが有れば教えてくれ。
6. このPHP流の参照仕様、使い道無いよな？実は冒頭の記事を読んだ当初、
> PHPの参照はいちど変数が参照になってしまうと、二度ともとに戻ることができないので、扱いにくくてやっぱりダメです。
　とあるので、参照は変数側に固定で、参照変数を値渡しの関数の引数にしても常に参照渡し、なら、
　スゲーカッケー！！！と思って試したが、全くそうじゃなかった。
　しかも参照渡しの関数の戻り値を普通に値変数として確保出来るし、「二度ともとに戻ることができない」というのが意味不明。
　Cみたいに呼ぶたびに自由に切り替えられることを想定しているのなら、それは過剰で、
　(そもそも元々出来たようだがPHP4.1.3で廃止された、というのを見た覚えがあるが、再確認出来ない）
　実際はRustみたいに「mutableな変数は最初から決まっているので宣言時に固定する」で問題ない。
　だからコピーオンライト（これってPHP.netでは書いてないだろ！今日初めて知ったわ！)で
　全部見た目は値渡し値返し、なら、凄く先進的ではあったのだが。
　（なお参照の取り扱いは他言語も苦労してて、C++でも失敗してる）

http://mevius.5ch.net/test/read.cgi/tech/1619667579/737

上下前次 1-新書関写板覧索設栞歴

あと 211 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.018s