却下されたPHP RFCを見てみる

2年ぶり。
この2年くらいで却下されたRFCが10個になってたので、それぞれを見てみます。

つまり、ここに紹介されたような内容は当面PHP本体に入ることはないということです。
もっともTyped Properties 2.0のように説得力を持たせれば逆転もできるので、何か提案したいと考えている人は参考にしてみてはどうでしょう。

Declined RFC

Making stdClass iterable

賛成7、反対25で却下。

stdClassをIterableにしよう、という提案。

PHPにはstdClassというビルトインクラスがありますが、これはJavaのObjectのような基底クラスというわけではなく、ただのクラスです。
基本的にユーザがstdClassを新規作成するようなことはあまりなく、json_decodeや(object)キャストなどの結果として返ってくるものがほとんどです。

stdClassはIterableでもないのにforeach可能なので、Iterableにしたほうが統一的なんじゃないかという主張でしたが却下されました。
InternalではそもそもstdClassを使うな的方向に向かっててどうなんだ。

元々オブジェクトに対する繰り返しは全ての可視プロパティが見れるという仕様が先にあって、今でもPDOやらDateTimeやらIterableじゃないのにforeachできるクラスが山のようにあるので、今さらstdClassだけIterableにしたところで意味がない気がしてならない。

iterable_to_array() and iterable_count()

iterable_to_arrayは賛成8、反対24で却下、iterable_countは賛成2、反対35で却下。

iterator_to_arrayなのにIterableを渡せない、どういうことだ、Iterableを配列にするメソッドがあってもいいはず、というRFCです。
任意のIterableを配列にするiterable_to_array、個数を数えるiterable_to_arrayが提案されましたが、両方とも却下されました。

まあ1行で書ける中身ですし、あと関数名が極めて誤認しやすいので、あると混乱しそうですね。

function iterable_to_array(Iterable $iterable){
	return is_array($iterable) ? $iterable : iterator_to_array($iterable);
}

User-defined object comparison

賛成5、反対12で却下。

オブジェクト同士の比較を独自に定義できるようにしよう、というRFC。
PHP以外の言語では大抵実装されているものです。

元々エクステンションでは==の定義を変更できるのですが、PHPでも変更できるようにマジックメソッド__compareToと__equalsを追加します。

class Example
{
    /**
     * <,>,<=>等による比較を行う
     * @param mixed 比較対象
     * @returns int $otherより大きければ1、小さければ-1、等しければ0
     */
    public function __compareTo($other): int
    {
        return $this <=> $other;
    }
 
    /**
     * ==による比較を行う
     * @param mixed 比較対象
     * @returns bool ==ならtrue
     */
    public function __equals($other): bool
    {
        return $this == $other;
    }
}

これによって、==、!=、<、<=などを独自に設定可能になります。

なお=== !==の定義は変更できません。
こちらは定義が『同じインスタンス』なので、さすがに変更できてしまうと困りますからね。

Class Friendship

賛成6、反対27で却下。

こちらで解説しています。
友達認定した相手は自分のprotectedやprivateを読めるようになる、というなかなか面白い機能です。

面白いだけで用途は一種類しか思いつきません。
テストクラスを指定することでリフレクション地獄を回避する、というものです。

でもこのRFCが通ったとして、PHPUnitからReflectionをなくせるかというとかなり非現実的な気がしますね。

Implement SQLite "openBlob" in PDO

賛成7、反対7で却下。

SQLite3::openBlobがPDOのSQLiteドライバに無いので追加してくれ、というRFC。

あんまりDB固有の機能までPDOで対応してしまうと今後ずっと面倒みないといけないからしない、とのことです。
そもそもBLOBをstreamで取得できるなんてこと自体知らなかったわい。

UUID

賛成17、反対22で却下。

一意なグローバル識別子UUID生成関数を追加しようというRFC。

却下の理由としては既にPECLやComposerによる実装があるし、PHPコアで実装するほどのものではないだろう、理由がひとつ。
あとなんかプルリクがこれまであまり見たことない程度には紛糾していたので、そのせいかもあるかもしれません。

そんなことよりuniqidの役立たなさをどうにかしてもらえないだろうか。

Unary null coalescing operator

賛成4、反対12で却下。

NULL合体単項演算子を導入しよう、という提案。

if($id ?? === 1 ){
	// 何か
}

// ↓と同じ
if(isset($id) && $id === 1 ){
	// 何か
}

毎回if( isset($_REQUEST['hoge']) && $_REQUEST['hoge'] === 'fuga' )とか書くのは面倒なんじゃ、というのはPHPerなら誰しも考えることですが、しかしRFCが間違ってるぞというツッコミを受けてあえなく撃沈。

RFCには$_GET["action"] ?? NULL === "submit"とisset($_GET["action"]) && $_GET["action"] === "submit"が同じと書いてあるのですが、実際は動作が異なります。
もう少し丁寧にRFCを推敲してから提出していたら結果も変わっていたかもしれませんね。

Doxygen

賛成11、反対16で却下。

ソースコードのドキュメントにDoxygenを導入しよう、という提案。
DoxygenはJavaDocに似た形式で、きちんと書かれたコメントから簡単にドキュメントを生成することができます。

自動生成ドキュメントをどこかに公開することでマニュアルよりも正確な情報を提供でき、ドキュメントであれば修正もたやすいのでソースコード変更への参入障壁も下がるからメンテナもきっと増えるぞと夢が広がりんぐ状態でしたが、MLでは昔やろうとしたけど諦めたとか、試しにやってみたけど死ぬわと評判は芳しくありませんでした。

まあ数千ある関数を今から対応していくのは並大抵の労力ではありませんしね。
最初から提唱者が1000個くらい対応したプルリクを送っていたら、満場一致で採択されたに違いありません。

Binary String Deprecation

賛成19、反対13で却下。

バイナリ文字列を削除しよう、という提案。

PHPは(binary)キャストをサポートしているのですが、実はこれ、(string)キャストと全く同じです。

zend_language_scanner.l

<ST_IN_SCRIPTING>"("{TABS_AND_SPACES}("string"|"binary"){TABS_AND_SPACES}")" {
	RETURN_TOKEN(T_STRING_CAST);
}

では何なのかというと、PHP6で内部コードがUnicodeになったときのために用意されたもののようです。
しかしPHP6は頓挫したため、今となっては無用の長物です。

ということでRFCになりましたが、将来また要るかもしれないだろということで却下されました。
いや、どう考えても要らない子だろう。
要るかもしれないからやっておこう、というのは全くの不要です。

Throwable code's type generalization

賛成13、反対11で却下。

Exception::$codeやThrowable::getCodeはint型って書いてあるのに、PDOをはじめPHP自体がこれに多々違反してるんだが、という指摘。

実際にZend FrameworkでPDOExceptionがstring返して来がやるといった実害も発生しています。

RFCは引数をmixedにしろという内容なので、逆に広くなりすぎて問題なので却下は妥当でしょう。
しかし実装が合ってないのももちろん問題なので、今後は実装を修正していくべきでしょう。

感想

うん、まあ、却下されて当然のRFCがほとんどという気がしてならない。
個人的には、採択したほうがよかったと感じるのはBinary String Deprecationくらいですかね。
Throwable code's type generalizationは実装をintに合わせるべきって主張なら受け入れられたかもしれない。