Comment le document de la magie (_call et _callStatic) les méthodes de IDEs

Après de nombreuses années de bonheur, de codage dans notepad++ et sublime, j'ai été conseillé de donner un IDE PHP un aller. Je suis d'essayer phpStorm et il semble beau. La complétion de code et de la documentation est une grande fonctionnalité, mais n'est pas pour moi lorsque la magie méthodes sont utilisées. Est-il un travail autour pour obtenir phpStorm pour comprendre ce qui se passe dans les méthodes magiques?

Notre situation est quelque chose comme ceci:

abstract class a {
    public static function __callStatic($method,$args)
    {
        if(strpos($method,"get_by_") === 0)
        {
            //do stuff
        } elseif(strpos($method,"get_first_by_") === 0) {
            //do stuff
        } elseif($method == "get_all") {
            //do stuff
        }
    }
}

class b extends a {
    //some more stuff
}

b::get_by_user_id(27);
b::get_first_by_id(156);
b::get_all();

La magie callStatic méthode nous permet d'obtenir une collection d'objets à l'aide de 1 ou plusieurs arguments qui composent l'appel de la fonction.

Je vois qu'il y a un @la déclaration de méthode pour l'utiliser dans ces cas, mais phpStorm est seulement la cueillette jusqu'à la première de ces déclarations. En outre, je ne peut définir le type de retour à mixtes où que je préfère être en mesure de la définir comme quelle que soit la classe, c'était appelé sur b dans mon exemple).

Des idées ou des suggestions serait très très bien reçus, merci.

POURQUOI TOUT LE MONDE PENSE QUE PRIMORDIAL _call EST UNE BONNE IDÉE?!!
Obtenu de dire, +1 de Brian commentaire dans le cas où aucune personne saine d'esprit va la trouver cette question. Les méthodes magiques sont à toutes fins utiles: undocumentable (essayez de le document a(n) [paramètre|condition|postcondtion|exception] pour une méthode magique), pas IDE de compagnie (essayez de l'étape de débogage d'une méthode magique), résistant à la refactorisation (s'il vous plaît, ne même pas envisager d'essayer de refactoriser une méthode magique dans un poste permanent morceau de logiciel), et PARESSEUX (ok, la dernière peut être interprétée comme un avis).
-1 pour l'opinion dans le commentaire de @LukeA.Leber qu'elle témoigne d'un manque de vision. Alors que les méthodes magiques ne sont pas une manière d'écrire moins de code (si vous les utilisez pour être paresseux), les méthodes magiques de faire architectures possibles que simple ne serait pas possible autrement ou qui serait ainsi outrageusement complexe, il ne serait pas utile d'écriture. Et ils sont complètement IDE sympathiques lors de l'utilisation de PHPDoc. Notez que la plupart du temps, vous n'avez pas besoin de méthodes magiques, mais quand vous en avez besoin, il n'y a pas de substitut (en PHP.) Lorsqu'ils sont utilisés dans un très structurée de la manière de les utiliser est un formulaire de solution valable.
Ne pense pas primordial __call est une mauvaise idée. Il est tout au sujet de la mise en œuvre. La mise en œuvre de la question ci-dessus aurait certainement pas être le meilleur moyen, mais pour la chaîne de mesure de l'API, il permet beaucoup de flexibilité.

InformationsquelleAutor Rob Forrest | 2013-03-26

132

Utilisation au niveau de la classe PHPDoc commentaire -- spécifiquement @méthode tag -- fonctionne très bien dans PhpStorm:
```
/**
 * @method static someClass get_by_user_id(int $id) Bla-bla
 * @method static someClass get_first_by_id(int $id) 
 */
abstract class a {
...
```
Ci-dessus:
- @method -- PHPDoc tag
- static -- raconte que c'est la méthode statique
- someClass ou $this -- type de retour
- get_by_user_id -- nom de la méthode
- (int $id) -- signature de la méthode: ([[type] [parameter]<, ...>])
- Bla-bla -- une description facultative
Plus sur @method:
- http://www.phpdoc.org/docs/latest/references/phpdoc/tags/method.html
- https://github.com/phpDocumentor/phpDocumentor2/blob/develop/docs/PSR.md#711-method
P. S.
Alors que @method static fonctionne très bien dans PhpStorm (dit IDE que la méthode est statique), il peut ne pas être (encore?) pris en charge par les phpDocumentor outil (désolé, ne l'avez pas utilisé pendant un certain temps).

Sinon: (dans PhpStorm, bien sûr) Settings | Inspections | PHP | Undefined | Undefined method --> Downgrade severity if __magic methods are present in class -- il ne va pas aider avec la complétion de code de ces méthodes, mais ne marque pas ces méthodes magiques comme "undefined method" erreurs.

phpDocumentor billet concernant l'utilisation de RegEx/noms partiels pour @property/@method balises (comment il peut être utile pour la documentation et le peu d'aide qu'elle peut apporter à l'effectif de l'IDE lorsque vous traitez avec la complétion de code):
- https://github.com/phpDocumentor/phpDocumentor2/issues/689
- Merci, cela ressemble à une suggestion raisonnable et il fonctionne certes dans phpStorm, mais je suis un peu détesté à écrire des centaines de lignes de @méthode en haut de chaque classe. Vous voyez le get_by_* méthode peut être ajouté par l'un des objets les paramètres pour obtenir les objets de ce type par le paramètre spécifié. Même en excluant la possibilité de get_by__et_ je finirais avec environ 1500 @methods à travers 140 classe différente. N'est-il pas un plus générique, de façon à fournir de la documentation?
- Pas de. Toutes les méthodes magiques doivent être déclarées en particulier (c'est le point principal de la documentation de cette façon) - PHPDoc ne comprenez pas une partie du nom (par exemple,get_by_*(int $id)). Pour les IDE (code de l'inspection, pas la fin!) vous avez alt solution (désactiver les avertissements). Pour phpDocumentor (ou autre outil) - pas de solution connue à moi (c'est peut-être là, mais je ne sais pas à ce sujet). Vous avez le lien vers github - file nouveau billet et demander l'ajout de ces "noms partiels" correspondant à des fonctionnalités de voir ce qu'ils vont dire (le plus probable sera rejetée). Si il sera mis en œuvre, puis l'IDE peut avoir en tant que bien plus tard.
- github.com/phpDocumentor/phpDocumentor2/issues -- mais s'il vous plaît vérifier si semblable billet n'existe pas avant de poster le vôtre.
- Merci pour tout cela. Il est actuellement ouvert billet en ce qui concerne cela, mais il semble avoir disparu calme. J'ai coincé un commentaire là-bas et nous allons voir ce qui vient de lui.
- Juste pour la référence, le phpDocumentor du billet (ainsi les autres utilisateurs de savoir ce billet vous parlez; également ajouté à la réponse elle-même): github.com/phpDocumentor/phpDocumentor2/issues/689
- On dirait que j'ai ouvert une boîte de pandore là!! Cela pourrait devenir intéressant.
InformationsquelleAutor LazyOne
4

Est en quelque sorte liée à la question d'origine:

Vous pouvez également définir ce dans phpstorm méta-fichier. Voici un exemple de méthode de fabrique (v2016.3):
```
//Define in .phpstorm.meta.php
namespace PHPSTORM_META {
    $STATIC_METHOD_TYPES = [
        \Factory::create('') => [],
    ];
}

//Then use in code
$factory = new \Factory();
$user = $factory->create(\User::class);
//Here you get autocomplete.
$user->subscribe();
```
De cette façon, vous n'avez pas à docblock toutes les possibilités où la magie se produit.

Ont certains docs pour plus de détails.
- Cela ne fonctionne pas avec __appel. Il n'est pas non documentées et non valides PHP. PHPStorm seulement fournit le support pour lequel vous avez définis de manière statique des méthodes qui renvoient un mélange de types en fonction de l'entrée.
InformationsquelleAutor Yauheni Prakopchyk

Vous devez vous connecter pour publier un commentaire.