Zend FR

Bon, pas la moindre réponse !

Finalement, je me suis débrouillé tout seul et j'ai fini par ajouter une méthode dans le bootstrap (héritant de Zend_Application_Bootstrap_Bootstrap).

Si cela peut servir à quelqu'un je pourrais éventuellement poster mon morceau de code.

Merci pour ta réponse thbenda.

J'ai regardé tout ça et j'ai compris le principe maintenant ^^

Pour ma part, j'utilise la version plus courte :

$this->_getParam('language');

- 'Favor the explicit over the magical',
- 'Additionally, "magic" methods such as _call(), get(), and _set() have performance implications; they take roughly 6x longer to execute than simply calling a standard method. By favoring explicit calls, we can likely radically improve the baseline performance of the framework.'

Je prend bonne note.

J'apprécie toujours les conseils au sujet des bonnes pratiques : donc un grand merci.

Autant prendre de bonnes habitudes dès le départ

En regardant le code, on s'aperçoit que la méthode _getParam($param [, $default]) est une méthode protégée qui fait exactement appel à $this->getRequest()->getParam($param) en lui autorisant une valeur par défaut :

    protected function _getParam($paramName, $default = null)
    {
        $value = $this->getRequest()->getParam($paramName);
        if ((null === $value) && (null !== $default)) {
            $value = $default;
        }

        return $value;
    }

Cela n'a rien à voir avec une méthode "magic" mais thbenda avait l'air de le penser

Cependant, cela peut peut-être légèrement ralentir le code car on fait quand même appel à une méthode supplémentaire qui rappelle ensuite la méthode voulue.

Bonjour,

Qu'elle soit magique ou pas, peu m'importe.
L'idée est qu'elle introduit une étape pas toujours nécessaire.

Quand tu as besoin d'une valeur par défaut pour ton paramètre, alors il te suffit de fixer la valeur par défaut de ton paramètre... pour être tranquille.

Le reste du temps, si tu n'as  pas besoin d'une valeur par défaut...

Bonne journée!

Oui, elles produisent le même résultat, et c'est bien normal!
C'est un accesseur... qui accède à la propriété pour la modifier selon les besoins du développeur.

Et oui, je me suis trompé sur la nature de la méthode _getRequest(), sans aucun doute à cause de cette fichue manie de préfixer méthodes et attributs par un underscore.... manie qui ne me plait pas du tout. Je préfère de très loin la notation CamelCase. Avec cette méthode, il devient impossible de confondre méthodes magiques et méthodes normales.

Par ailleurs, je tiens à faire remarquer que les méthodes magiques du langage PHP prennent 2 underscores comme préfixe... On les distingue facilement grâce à cela:
C'est du code comme ceci:

__autoload()
__call()
__init()
__get()
__set()
__toString()

Sans doute la notation rappelée par Matthew et reportée par calvey m'a-t-elle involontairement induite en erreur.
cf ce post plus haut.
A moins que le comportement ne soit pas aussi simple que le prototype de la méthode _getParam() pourrait le laisser penser: préfixer les méthodes d'un underscore quand elles font appel à des méthodes magiques dans les classes sous-jacentes du framework. Et puis, je doute que Matthew se soit trompé dans son article.

Dernière modification par thbenda (18-06-2010 13:33:41)

Merci pour ce lien, utile.
Donc ce n'est qu'une simple question de visibilité de méthodes... et non pas une question de méthodes magiques.

Question:
Pourquoi ajouter un élément (l'underscore) qui ne sert strictement à rien ?
Si tu veux connaître la visibilité d'une méthode tu te reportes à son prototype dans sa classe: public, protected, private, portée locale. Point barre !

Il faudra vraiment que je prenne le temps de lire tranquillement les arguments développés sur ce lien.
Lien lu, pas d'arguments pour l'application de cette convention de nommage. Juste pour le fun de se compliquer la vie, tout simplement.



Remarques:
1. Zend Framework n'est pas un langage, mais un Framework qui utilise un langage (le PHP ici).

2. C'est pas la première fois que je m'énerve contre ce type de pratique totalement absurde qui n'engendre de la complexité là où il ne devrait pas y en avoir (aussi bien en JAVA qu'en PHP).

Dernière modification par thbenda (18-06-2010 14:55:21)

calvey a écrit:

Je ne peux pas tout expliquer, mais l'utilisation de conventions comme l'underscore préfixant les éléments protégés ou privés à pour but de faciliter la reprise du travail par d'autres développeurs.

Je connais et je comprends tout à fait les raisons liées à certaines conventions de codage.
Seulement, il n'est pas établi que cela facilite systématiquement le travail d'autres développeurs...
Car trop souvent, il faut chercher dans la documentation (quand elle existe) la trace des conventions de codage (quand elles y sont abordées) utilisées par les développeurs sur un projet quelconque...

Quant à la notation hongroise, elle me parait aussi expressive que la notation CamelCase.
Elles sont toutes deux porteuses de sens, sans nécessité d'expliciter en annexe.
C'est nettement moins le cas ici, où nous sommes obligés de consulter la documentation pour dissiper un malentendu possible.

calvey a écrit:

L'intérêt de préfixer par un underscore est tout bêtement de ne pas avoir à chercher dans le code la visibilité (ou portée) de la méthode (ou de la propriété).

Avec les EDIs actuels tels que Eclipse ou Netbeans, la recherche dans le code se limite aujourd'hui à un clic sur la méthode pour voir son prototype apparaître. Même des éditeurs de texte tels que Scite , jEdit ou autres permettent ce genre de fonctionnalités via l'ajout de plugins dédiés à un langage particulier.


Allez, j'arrête de causer pour un si petit underscore
Bonne fin de journée!

Dernière modification par thbenda (18-06-2010 15:53:38)