Pourquoi PHP 5.2+ interdire résumé statiques les méthodes de la classe?

C'est une longue et triste histoire.

Lors de PHP 5.2 de la première introduction de cet avertissement, late static bindings n'étaient pas encore dans la langue. Dans le cas où vous n'êtes pas familier avec les late static bindings, notez que ce code ne fonctionne pas de la même façon que vous pouvez attendre de nous:

<?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();

En laissant de côté le mode strict avertissement, le code ci-dessus ne fonctionne pas. Le self::bar() appel dans foo() explicitement référence à la bar() méthode de ParentClass, même lorsque foo() est appelée comme une méthode de ChildClass. Si vous essayez d'exécuter ce code avec le mode strict off, vous verrez "PHP Fatal error: Impossible d'appeler la méthode abstraite Myclass::bar()".

Compte tenu de cela, résumé des méthodes statiques dans PHP 5.2 étaient inutiles. Le tout le point de l'utilisation d'une méthode abstraite est que vous pouvez écrire du code qui appelle la méthode sans le savoir la mise en œuvre qu'il va être à l'appel, et ensuite fournir des implémentations différentes sur les différentes classes enfant. Mais depuis PHP 5.2 offre pas de propre façon d'écrire une méthode d'une classe parent qui appelle une méthode statique de la classe enfant sur lequel elle est appelée, cette utilisation de résumé des méthodes statiques n'est pas possible. Par conséquent, l'utilisation de abstract static en PHP 5.2 est un mauvais code, probablement inspiré par une incompréhension de la façon dont le self mot clé fonctionne. Il était tout à fait raisonnable de lancer un avertissement sur ce.

Mais alors PHP 5.3 est venu ajouté dans la capacité à se référer à la classe dans laquelle la méthode a été appelée par le static mot-clé (à la différence de la self mot-clé, qui fait toujours référence à la classe dans laquelle la méthode a été défini). Si vous modifiez self::bar() à static::bar() dans mon exemple ci-dessus, il fonctionne très bien en PHP 5.3 et au-dessus. Vous pouvez en lire plus à propos de self vs static à Nouvelle auto vs statique.

Avec le mot-clé static ajoutée, l'argument clair pour avoir abstract static lancer un avertissement avait disparu. Late static bindings' objectif principal était de permettre à des méthodes définies dans une classe parente, pour appeler des méthodes statiques qui seront définies dans les classes enfant; permettre résumé des méthodes statiques semble raisonnable et cohérent compte tenu de l'existence late static bindings.

Vous pouvez toujours, je suppose, faire un cas pour le maintien de l'avertissement. Par exemple, on pourrait dire que depuis PHP vous permet d'appeler des méthodes statiques de classes abstraites, dans mon exemple ci-dessus (même après fixation par le remplacement de self avec static) vous êtes exposant une méthode publique ParentClass::foo() qui est cassé et que vous ne voulez pas vraiment de les exposer. À l'aide d'un non-statique de la classe - qui est, en faisant toutes les méthodes de de méthodes d'instance et de rendre les enfants de ParentClass tous les singletons ou quelque chose - permettrait de résoudre ce problème, depuis ParentClass, abstrait, ne peut pas être instanciée, et donc ses méthodes d'instance ne peut pas être appelé. Je pense que cet argument est faible (car je pense que d'exposer ParentClass::foo() n'est pas une grosse affaire, et à l'aide de singletons au lieu de la statique des classes est souvent inutilement verbeux et laid), mais vous pourriez raisonnablement en désaccord - c'est un peu subjectif, appel.

Donc sur la base de cet argument, les devs PHP gardé l'avertissement dans la langue, non?

Euh, pas exactement.

PHP rapport de bug 53081, ci-dessus, appelé pour que l'avertissement puisse être diminué depuis l'ajout de la static::foo() construire en avait fait abstrait des méthodes statiques raisonnable et utile. Rasmus Lerdorf (créateur de PHP) commence par l'étiquetage de la demande que de faux et passe par une longue chaîne de mauvais raisonnement pour tenter de justifier l'avertissement. Puis, enfin, de cet échange:

Giorgio

je sais, mais:

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();

Rasmus

Droit, qui est exactement la façon dont il devrait fonctionner.

Giorgio

mais il n'est pas permis 🙁

Rasmus

Ce n'est pas permis?

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

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

cB::A();

Cela fonctionne bien. Évidemment on ne peut pas appeler self::B(), mais statique::B()
est fine.

La demande par Rasmus que le code dans son exemple "fonctionne très bien" est faux; comme vous le savez, il jette à un strict mode d'avertissement. Je suppose qu'il a été le test sans le strict mode est activé. Peu importe, une confusion Rasmus gauche la demande fermé par erreur comme "bidon".

Et c'est pourquoi l'avertissement est toujours dans la langue. C'est peut-être pas entièrement satisfaisante explication - vous avez probablement venu ici en espérant y a une justification rationnelle de l'avertissement. Malheureusement, dans le monde réel, parfois, les choix sont nés de banals les erreurs et les mauvaises raisonnement plutôt qu'à partir d'une prise de décision rationnelle. C'est tout simplement un de ces moments.

Heureusement, l'estimable Nikita Popov a supprimé l'avertissement de la langue en PHP 7 dans le cadre de PHP RFC: Reclasser E_STRICT avis. En fin de compte, la santé mentale qui a prévalu, et une fois de PHP 7 est sorti, nous pouvons tous heureusement utilisation abstract static sans réception de ce stupide avertissement.

Je sais que c'est vieux, mais....

Pourquoi ne pas simplement jeter une exception que le parent de la classe de la méthode statique, de cette façon, si vous ne la supplante pas l'exception en soit la cause.

Je ne vois pas de raison d'interdire statique résumé des fonctions. Le meilleur argument qu'il n'y a pas de raison de les interdire, c'est qu'ils sont autorisés en Java.
Les questions sont:
- Sont techniquement réalisable? - Oui, depuis le existé en PHP 5.2 et ils existent en Java.
Donc, on PEUT le faire. DEVRIONS-nous le faire?
- Ont-elles un sens? Oui. Il est donc logique d'appliquer une partie d'une classe et de laisser l'autre partie d'une classe à l'utilisateur. Cela a du sens dans le non-statique fonctions, pourquoi ne devrait-il pas du sens pour les fonctions statiques? Une utilisation de fonctions statiques sont des classes où il ne doit pas y avoir plus d'une instance (singletons). Par exemple un moteur de chiffrement. Il n'a pas besoin d'exister dans plusieurs cas, et il y a des raisons pour éviter cela - par exemple, vous avez à protéger que d'une partie de la mémoire contre les intrus. Il est donc parfaitement logique pour mettre en œuvre une partie du moteur et laisser l'algorithme de chiffrement de l'utilisateur.
Ce n'est qu'un exemple. Si vous êtes habitué à utiliser des fonctions statiques, vous trouverez beaucoup plus.

Regarder dans PHP 'Late Static Binding questions. Si vous mettez les méthodes statiques de classes abstraites, vous allez probablement avoir à l'utiliser plus tôt plutôt que plus tard. Il est logique que le strict avertissements vous dire d'éviter d'utiliser cassé fonctionnalités de langage.