今週の PHP 2023-12-30 〜 2024-01-12
PHP のメーリングリストから、気になった情報をピックアップします。
※年末年始は更新少なめだったので二週間分まとめてます。
Internal
PHP: rfc:http-last-response-headers
http_get_last_response_headershttp_clear_last_reponse_headers
magic変数である $http_response_header を置き換えるための関数提案です。
PHP: $http_response_header - Manual
これ使ったことなかったんですけど、まじで魔法ですね。ローカルスコープで変数に値が入るんですね....
stream_context の一部にしたら？という提案がコメントされてましたが、stream_contextもまあ大概だよなぁなどと思ってみていました。既存のmagic変数よりはいずれにしろ可読性とか、ソースコードの見た目の納得感とかは上がるので良さそうだなと思いました。
リリース候補
それぞれ、リリース候補版が出ているようです。興味のあるかたは是非。
PHP: rfc:policy-repository
様々な決め事について、ドキュメントを一つのポリシーリポジトリにまとめようよというRFCですが、投票に入りました。問題なく可決されそう。
PHP: rfc:promote_php_foundation
php.netのウェブサイト内にPHP Foundationのリンクを追加しましょうというRFCです。以前話し合われていたやつですが、現在OSSとしてのコミュニティの主体はPHP Foundationにあるので、そうあるべしという感じです。
PHP-8.0 End of Life - Externals
みなさんの愛してくれたPHP8.0がEOLです。公式なSecurity Fixはこれがラストです。
内緒の話ですが、Ubuntu20.04LTSがPHP7.4のサポートを2030年までやってるので、多分2030年までは誰かがどうにかSecurity Fixは入れてくれると思います。
https://wiki.ubuntu.com/Releases
PHP: rfc:resource_to_object_conversion
一月ほど前に議論されていた Resource を Object に変換する件ですが、投票が開始されました。
基本的な考えとしては、変換を強制するものではなく、将来のとある時点で強制も可能であるような状態にもっていくための下準備といったニュアンスが大きいです。そのため後方互換性を重視しながら一般的にも許容される方針について採決を取っている感じです。
全体としては可決は間違いなさそうで、どのような変更をどのタイミング（8.4 or 9.0) で入れるのかというのが一つの論点になっています。
PHPについて詳しくなろうとすると「そもそもResourceって何なの？」という疑問が必ず出てきて、拡張ごとにちょっとずつルールが違うので場合に依る。みたいな解答になりがちだったものに統一的な仕様が導入されるのは良いことだなぁと思います。
Google Summer of Code 2024 - Externals
Program Details | Google Summer of Code に団体として応募しない？というお便り。
今のところ返信なし。
Declaring new elements as references while destructuring within a foreach() head - Externals
foreach で配列の中身を破壊的に変更できるってバグですか？というお便り
PHP 7.3 以上であれば、listにreferenceを突っ込めるようで、動作しています。
解説としては、Internalの返信の下記のコードが自分にはわかりやすかったです。要するに配列の特定要素にたいしてreferenceを設定しているという形になっています。（この日本語表現合ってる？？）
$v = & $arr['foo'];
とはいえ、仕事のプログラムでは見たくない書き方だなと思いました。コードゴルフとかで役に立つことがあるのかもしれない。（一部のマニア向け）
PHP: rfc:rfc1867-non-post
POST以外でも本来使えて欲しいmultipart/form-dataのリクエストのパースをユーザーランド向けの関数によって可能にするというRFCです。
スーパーグローバルである $_POST $_FILE に値が入って欲しいけど、 PATCHやPUTでは値が入ってくれないので、自前で生のリクエストをパースする必要があって辛いという話からでした。
request_parse_body() という関数を実行することでユーザーランドでも簡単にパースできるようにしようというものです。コード例は下記
[$_POST, $_FILES] = request_parse_body();
RFCに対するコメントは概ね好意的であり、作成者の方もフィードバックを次々と取り入れているので、このRFCはうまく行きそうな予感です。 post_max_size とかの設定も関係してくるのだろうけど、PUTでもpost_max_sizeなのかな？とか、ちょっと気になりますね。
Multibyte for ucfirst function - Externals
ucfirst 関数のマルチバイト版を追加するリクエストが来てるけどどうなのよ？というお便り。
以前も議論されてたし、いいんじゃね？とのこと
Discussion