今週の PHP 2022/09/03 〜 2022/09/09
PHP のメーリングリストから、気になった情報をピックアップします。
Internal
RFC Asymmetric visibility
議論は続いています
Larry さんからは、非公式のアンケート依頼が来ています。
要するに、非対称可読性を実装するにあたって、どの文法がいい？というご意見希望です。
興味のある方は、アンケートに協力してあげてください。
アンケートに含まれない表現方式の提案もきていて
public(get) private(set) string $bar;
冗長にも見える。 explicit over implicit という気持ちも分かる。
Issues with readonly classes
lazy-loading proxy generation を Readonly class で試している方から、以下の３つが出来なくてこまるというご意見
- Declare a new non-readonly property;
- Have static properties;
- Have dynamic properties.
私の理解では、遅延ローディングを Readonly クラスに適用する場合に、一度生成されたクラスのプロパティに対して、いかなるプロパティも追加できないから困るということだと思う。
この意見に対しては、遅延ローディングを Readonly クラスでやるなよという返信。
Readonly は、生成された時点でプロパティの値が決定されていることが一番の目的だと思うので、遅延ローディング出来ないのは正しいと、私なんかも思ってしまいます。
議論はつづき、遅延ローディングは一例に過ぎない。いかなる継承ベースのデコレーターも難しい。なぜなら、clone してもプロパティの制限が変えられないからというコメント。
なぜ、clone の話が出てくるのか、良くわからなかったけど、immutable 過ぎて使いづらいという意味合いだろうか。
新規フィーチャーが、あなたのユースケースに合わないというだけではという意見。
いやいや、Readonlyクラスは、いかなるプログラミング理論にも裏打ちされていない新しいコンセプトだ。
そして、コレによって既存の継承に関する仕組みが破壊されている（例、継承ベースのproxy decorator）
であれば、readonly クラスのフラグを、子クラスに伝播させることについても、修正するかどうかを議論すべきだ！と
他の、どんな言語にも readonly クラスなんて、ないやないか！と
コレに対して、C# には readonly struct がある、record という仕組みもある。
record は record との継承はできるが、通常クラスとは出来ない。with を使うことで clone する抜け道もある。との意見
その後は、Readonly の RFC 作者も入って、議論は続き、clone 時は値の変更を許容してもいいかもしれない。などの抜け道についても話し合われていました。
ともあれ、readonly という 値が変更されていないことが確定しているオブジェクトを作れる仕組み自体は、とても良いと思うので、もっと活発な議論を経て、妥当な仕組みにおさまっていけばと願います。
Increase maximum size of an uploaded file to 50Mbyte
現状のデフォルト値は 2MB
iPhone X の写真が 8MB の時代に、小さすぎやしないか？という話
50MB にしようぜ！という提案です。すでに PR もあります。
まあ、たしかに。よく訓練された PHPer は、ファイルアップロード機能がある場合に、最大ファイルサイズを仕様として定めた上で、各種設定値を変更するという行動にでます。
そうじゃない人にとっては、この辺はわかりにくいポイントになるかもしれません。
post_max_size とか知らんよねぇ。
コレに対する反応は...
まあ、いいとは思うけど 50MB はでかいよ。
あと、php.ini とか、デフォで配置されてないよ Linux は！ということで、直で変えようという提案
いやいや、DevOps エンジニアだったら、自分のサービスの php.ini を適切に管理すべき
とはいえ、変更するのはいいと思う。50MB はでかいがな。という意見
20MB ではどうだろう？という意見
これって、RFC必要？
-> とても小さな変化だし、新しい Feature ではないから不要
RFC [Discussion]: Improve unserialize() error handling
unserialize のエラーハンドリングを改善しようという RFC の提案前相談スレッド
すでに RFC は出されている
PoC も出ている
もともとは、8.2 の新機能である ext-Random の実装時に出てきた課題でもあります。
RFC では、E_NOTICE を出している箇所は、E_WARNING に昇格させ
UnserializationFailedException をスローするという実装にしようという提案がされています。
__unserialize の実装をどうするか？という疑問から派生していまして、以前に今週のPHPでも取り上げました。
各拡張で、実装がマチマチという問題でした。
ext/gmp: Exception
ext/hash: Exception
ext/date: Error
ext/spl: UnexpectedValueException
ext/random: Currently Exception.
E_NOTICE が出てくる場合もあるということで、 E_WARNING に統一すべき。9.0 以降は、例外 (Exception) に昇格させようという話がされています。
中には、現状はハンドリングが難しすぎるから、すぐに例外に昇格させようという意見もあります。
上の例にもあるとおり、現状では catch (\Throwable) で Error と Exception の両方を取らないといけません。また、E_NOTICE でエラーハンドラーを動かす必要もあるので、ちょっと実装は厳しいなという印象です。
Exception として統一されれば、ユーザーランドのソースコードは、統一的に unserialize が扱えるようになって、安全になりそうですね。
細かい議論は続いておりまして、RFC は随時更新されています。
Bugs
Fix memory leak triggered by unsuccessful dynamic property unserialization by kocsismate · Pull Request #9468 · php/php-src
動的プロパティに起因するメモリリークの修正
Fix GH-9139: Allow FFI in opcache.preload when opcache.preload_user=root by arnaud-lb · Pull Request #9473 · php/php-src
preloading が root で行われている場合は FFI の使用を許可しようというPR
merge された！
Setting opcache.interned_strings_buffer to a very high value leads to corruption of shm · Issue #9259 · php/php-src
opcache.interned_strings_buffer に 16M などの大きい値を設定すると shm が崩壊してエラーが出てしまうというイシュー
修正はこちら。
メモリのアロケーションに失敗したら、エラーを出すようになっていますね。
Log error cause when opcache cannot write to file cache by arnaud-lb · Pull Request #9258 · php/php-src
Opcacheまわりの細かい修正が行われているようです。
fuzzer sapi little memory related fixes here and there. by devnexen · Pull Request #9480 · php/php-src
そもそも fuzzer っていう SAPI は何なんですか？というところ
mb_detect_encoding() detects UTF-8 emoji byte sequence as ISO-8859-1 since PHP 8.1 · Issue #7871 · php/php-src
Discussion