PHP 5.2+が抽象静的クラスメソッドを許可しないのはなぜですか？

PHP 5.2で厳格な警告を有効にした後、元々厳格な警告なしで作成されたプロジェクトからの一連の厳格な標準警告が表示されました。

厳密な標準：静的関数 Program :: getSelectSQL（）は Program.class.inc で抽象であってはなりません

問題の関数は、抽象親クラスProgramに属しており、TVProgramなどの子クラスに実装する必要があるため、抽象staticと宣言されています。

私はこの変更への言及をここで見つけました：

抽象静的クラス関数を削除しました。見落としのため、PHP 5.0.xおよび5.1.xでは、クラスで抽象静的関数を使用できました。PHP 5.2.x以降では、インターフェースのみがそれらを使用できます。

私の質問は次のとおりです。なぜPHPに抽象静的関数を使用すべきではないのか、誰かが明確に説明できますか？

静的メソッドは、それらを宣言したクラスに属します。クラスを拡張するとき、同じ名前の静的メソッドを作成できますが、実際には静的抽象メソッドを実装していません。

静的メソッドでクラスを拡張する場合も同様です。そのクラスを拡張して同じシグネチャの静的メソッドを作成する場合、実際にはスーパークラスの静的メソッドをオーバーライドしていません

編集（2009年9月16日）
これに関する更新。PHP 5.3を実行すると、抽象または静的が復活しました。（詳細については、http：//php.net/lsbを参照してください）

CORRECTION（philfreoによっては）
abstract staticまだPHP 5.3で許可されていない、LSB関連するが異なるされます。

それは長くて悲しい話です。

PHP 5.2でこの警告が初めて導入されたとき、遅延静的バインディングはまだ言語に含まれていませんでした。遅い静的バインディングに慣れていない場合は、次のようなコードは期待どおりに機能しないことに注意してください。

<?php

abstract class ParentClass {
    static function foo() {
        echo "I'm gonna do bar()";
        self::bar();
    }

    abstract static function bar();
}

class ChildClass extends ParentClass {
    static function bar() {
        echo "Hello, World!";
    }
}

ChildClass::foo();

厳格モードの警告は別として、上記のコードは機能しません。のメソッドとして呼び出された場合でも、self::bar()呼び出しはfoo()明示的にのbar()メソッドを参照します。ストリクトモードをオフにしてこのコードを実行しようとすると、「PHPの致命的なエラー：抽象メソッドParentClass :: bar（）を呼び出せません」が表示されます。ParentClassfoo()ChildClass

このため、PHP 5.2の抽象静的メソッドは役に立たなかった。全体のポイントとし、別の子クラスの異なる実装を提供-抽象メソッドを使用するのは、あなたがそれを呼び出すことになるだろうどのような実装を知らなくてもメソッドを呼び出すコードを書くことができるということです。しかし、PHP 5.2では、親クラスのメソッドを、それが呼び出された子クラスの静的メソッドを呼び出すための明確な方法を提供していないため、この抽象静的メソッドを使用することはできません。したがってabstract static、PHP 5.2でのの使用はすべて、不適切なコードであり、おそらくselfキーワードの機能の誤解に影響を受けています。これについて警告を投げることは完全に合理的でした。

しかし、その後、PHP 5.3が追加され、staticキーワードを介してメソッドが呼び出されたクラスを参照する機能が追加されました（self常に、メソッドが定義されたクラスを参照するキーワードとは異なります）。上記の例でに変更self::bar()するstatic::bar()と、PHP 5.3以降で問題なく機能します。あなたは、詳細について読むことができるself対staticで新しい静的対新しい自己。

staticキーワードが追加されたためabstract static、警告をスローしたという明確な議論はなくなりました。遅延静的バインディングの主な目的は、親クラスで定義されたメソッドが、子クラスで定義される静的メソッドを呼び出せるようにすることでした。遅い静的バインディングが存在することを考えると、抽象静的メソッドを許可することは合理的で一貫しているように見えます。

あなたはまだ、警告を維持するための主張をすることができると思います。たとえば、PHPでは抽象クラスの静的メソッドを呼び出すことができるため、上記の例では（で置き換えselfて修正した後でもstatic）壊れているパブリックメソッドParentClass::foo()を公開していて、本当に公開します。非静的クラスを使用すると、つまり、すべてのメソッドをインスタンスメソッドにして、すべての子をシングルトンか何かにすることで、この問題を解決できます。呼ばれる。この議論は弱いと思います（ParentClassParentClassParentClass::foo() これは大したことではなく、静的クラスの代わりにシングルトンを使用することは、多くの場合、不必要に冗長で醜いです）が、あなたは合理的に同意しないかもしれません-それはやや主観的な呼び出しです。

それで、この議論に基づいて、PHP開発者は言語で警告を続けましたね？

ええと、正確ではありません。

上記のリンクのPHPバグレポート53081は、static::foo()構造の追加により抽象静的メソッドが合理的かつ有用になったため、警告を削除するように求めていました。Rasmus Lerdorf（PHPの作成者）は、リクエストを偽のラベルとしてラベル付けすることから始め、警告を正当化するために長い推論の長い連鎖を通過します。次に、最後にこの交換が行われます。

ジョルジョ

知ってるけど：

abstract class cA
{
      //static function A(){self::B();} error, undefined method
      static function A(){static::B();} // good
      abstract static function B();
}

class cB extends cA
{
    static function B(){echo "ok";}
}

cB::A();

ラスムス

そう、それはまさにそれが働くべきである方法です。

ジョルジョ

しかし、それは許可されていません:(

ラスムス

何が許可されていませんか？

abstract class cA {
      static function A(){static::B();}
      abstract static function B();
}

class cB extends cA {
    static function B(){echo "ok";}
}

cB::A();

これは正常に動作します。明らかにself :: B（）を呼び出すことはできませんが、static :: B（）で十分です。

彼の例のコードが「正常に機能する」というラスムスの主張は誤りです。ご存知のように、それは厳格なモード警告をスローします。strictモードをオンにせずにテストしていたと思います。とにかく、混乱したラスムスはリクエストを誤って「偽物」として閉じたままにしました。

そしてそれが警告がまだ言語である理由です。これは完全に満足できる説明ではないかもしれません-あなたはおそらく警告の正当な正当化があったことを望んでここに来ました。残念ながら、現実の世界では、合理的な意思決定からではなく、ありふれた過ちや悪い推論から選択が生まれることがあります。これは単にそれらの時代の1つです。

幸運なことに、推定可能なNikita Popovは、PHP RFCの一部としてPHP 7の言語から警告を削除しました：E_STRICT通知の再分類。結局のところ、正気が広まり、PHP 7がリリースされるとabstract static、このばかげた警告を受け取らなくても、誰でも楽しく使用できます。

この問題には非常に単純な回避策があり、実際には設計の観点からは理にかなっています。ジョナサンが書いたように：

静的メソッドでクラスを拡張する場合も同様です。そのクラスを拡張して同じシグネチャの静的メソッドを作成する場合、実際にはスーパークラスの静的メソッドをオーバーライドしていません

したがって、回避策としてこれを行うことができます：

<?php
abstract class MyFoo implements iMyFoo {

    public static final function factory($type, $someData) {
        // don't forget checking and do whatever else you would
        // like to do inside a factory method
        $class = get_called_class()."_".$type;
        $inst = $class::getInstance($someData);
        return $inst;
    }
}


interface iMyFoo {
    static function factory($type, $someData);
    static function getInstance();
    function getSomeData();
}
?>

次に、MyFooをサブクラス化するすべてのクラスがgetInstance静的メソッドとパブリックgetSomeDataメソッドを実装するように強制します。また、MyFooをサブクラス化しない場合でも、iMyFooを実装して同様の機能を持つクラスを作成できます。

これが古いのは知っているけど……

親クラスの静的メソッドに例外をスローするだけではなく、オーバーライドしないと例外が発生します。

抽象クラス/インターフェースはプログラマー間の契約と見なすことができると私は主張します。それは物事がどのように見える/振る舞うべきか、そして実際の機能を実装しないべきかについてより多く扱います。php5.0と5.1.xに見られるように、php開発者がそれを行うのを妨げるのは自然な法則ではありませんが、他の言語で他のOO設計パターンと一緒に進みたいという衝動があります。基本的にこれらのアイデアは、すでに他の言語に精通している場合、予期しない動作を防止しようとします。

静的抽象関数を禁止する理由は何もありません。それらを禁止する理由がないという最高の議論は、それらがJavaで許可されているということです。質問は次のとおりです。-技術的に実現可能ですか？-はい、PHP 5.2に存在し、Javaに存在するため。だからそれができるのです。私たちはそれをすべきですか？-彼らは理にかなっていますか？はい。クラスの一部を実装し、クラスの別の部分をユーザーに任せることは理にかなっています。非静的関数では意味がありますが、静的関数では意味がないのはなぜですか？静的関数の1つの使用法は、複数のインスタンス（シングルレット）があってはならないクラスです。たとえば、暗号化エンジン。複数のインスタンスに存在する必要はなく、これを防止する理由があります。たとえば、メモリの一部のみを侵入者から保護する必要があります。したがって、エンジンの一部を実装し、暗号化アルゴリズムをユーザーに任せることは完全に理にかなっています。これはほんの一例です。静的関数を使い慣れている場合は、さらに多くのことがわかります。

PHP 5.4以降では、特性を使用します。

trait StaticExample {
    public static function instance () {
    return new self;
    }
}

そしてあなたのクラスで最初に置く：

use StaticExample;

PHPの「遅延静的バインディング」の問題を調べてください。静的メソッドを抽象クラスに配置する場合は、おそらく後で実行するよりも早く実行するでしょう。厳密な警告が、壊れた言語機能の使用を回避するように指示していることは理にかなっています。