Discussion :

[RideKick]

Salut

Depuis plusieurs mois, la discussion sur la meilleure manière d'implémenter les espaces de noms (namespaces) en PHP ne cesse d'être alimentée par de nouveaux arguments.

Je pensais que les développeurs core trouveraient une solution simple et rapide, mais visiblement ils se heurtent à des cas d'utilisation parfaitement opposés et il leur est difficile de tomber d'accord. Une nouvelle RFC a donc vu le jour afin de proposer d'utiliser les accolades {} pour les espaces de noms (ce qui n'est pas le comportement actuel) : http://wiki.php.net/rfc/namespacecurlies

L'implémentation actuelle est telle que je l'ai décrite dans mon cours : http://g-rossolini.developpez.com/tu...page=poo#LIV-B
Une alternative est d'obliger l'utilisation des accolades, ce qui pose le problème de l'indentation mais qui permet d'inclure du code hors-namespace dans le même script.
Une autre question est la hiérarchie des espaces de noms : est-ce utile, est-ce nécessaire ?

Voici la discussion internals@ qui accompagne la nouvelle RFC : http://marc.info/?l=php-internals&m=122018993030061&w=2
Stanislav y a bien entendu répondu : http://marc.info/?l=php-internals&m=122034228323300&w=2

OK, I would be happy to hear these other people - what are they use cases and what they try to do with namespace nesting. Other people, please speak.

Qu'en pensez-vous ? Comment voyez-vous l'utilisation des namespaces en PHP ?

[B.Moncef]

Personnellement je pencherais plus en faveur de la syntaxe avec accolades, principalement parce que ça permet d'avoir du code hors-namespace dans le même fichier.

Pour ce qui est de la hiérarchie des namespaces, je ne sais pas exactement ce que c'est, je ne m'aventurerais donc pas à en parler.

[Yogui]

Le problème des accolades est que cela incite à indenter le code, donc a priori tout le code du script (ie. à tout décaler de 3-4 espaces ou d'une tabulation), ce qui bien évidemment est absurde

Pour la hiérarchie, il s'agit simplement de pouvoir déclarer un espace de noms dans un autre. Il y a des exemples à la fois dans mon cours et dans le message de Stanislav (cf. liens ci-dessus).

Concernant le code hors namespace, c'est justement le coeur de la question : dans quel cas cela te serait-il utile ? Si tu pouvais détailler et si nous avons plusieurs cas d'utilisation comme le tien, cela fera avancer la discussion sur intrnals@

[B.Moncef]

Je n'ai pas vraiment d'exemple pertinent sur le moment de l'utilité du code hors-namespace. S'il m'en vient un à l'esprit je ne manquerais pas de le citer.

Si la hiérarchie des namespaces est bien adoptée, on pourrait avoir besoin de définir un namespace, et un autre namespace "enfant" de celui ci dans un même fichier. Est-ce possible sans la syntaxe avec accolades ?

EDIT : Personnellement je vois la hiérarchie des namespaces comme complémentaire aux deux syntaxes ; Je veux dire on peut avoir la syntaxe 1 + hiérarchie, ou bien syntaxe 2 + hiérarchie.
Mais les options du sondage actuelles la présentent comme une alternative à ces deux syntaxes. N'aurais-je pas saisi quelque chose ?

Pour le problème d'indentation, ça dépends des personnes. Personnellement ça ne me dérangerais pas d'ajouter un léger décalage (pourquoi pas plus petit que les indentations "ordinaires" (1 espace, voir 2)).

[Ashgenesis]

Rajouter des accolades nous "oblige" à indenter encore d'un niveau le code ce qui peux commencer à être problématique si l'on tiens à garder des noms de variables qui veulent dire quelque chose et que l'on conserve la règle de limitation du nombre de caractère à 80. On pourrait passer à 120 comme le tolère les règles de codage Zend que j'utilise mais je ne trouve pas cela très propre.

Pour ce qui est du code hors namespace je n'en vois pas trop l'intérêt, un code hors namespace ne serait-il pas équivalent à un code avec un namespace différent?

C'est juste une petite réflexion et si vous avez des arguments contraires n'hésitez pas.

[Yogui]

Exactement, l'ajout d'un niveau d'accolades encourage l'ajout d'un niveau de tabs supplémentaires, et l'un des argmuents est en effet la limite habituelle de 80 ou 120 caractères par ligne.
Si on décide d'avoir des accolades en faisant une exception pour l'indentation, que ce soit pour mettre une indentation plus faible ou pour la supprimer, cela va devenir très complexe à gérer dans les IDE.
Si on décide d'avoir les accolades, ce qui semble parfaitement logique puisque les espaces de noms ressemblent à un groupement du code par blocs similaire à function, class etc., alors il n'y a aucune raison de ne pas ajouter un niveau d'indentation (surtout si on a une hiérarchie de namespaces).

Ces arguments tournent malheureusement en rond, il n'y a pas de solution idéale, ce qu'il nous faut c'est surtout un vote des préférences de chacun
Cela dit, nous pouvons repasser ici tous les arguments pour et contre chaque solution, je n'y vois pas d'inconvénient.

Concernant la hiérarchie, le parseur de PHP (aussi bien l'ancien que le nouveau) peut facilement permettre à peu près ce que l'on veut. Il n'y a pas vraiment de syntaxe "impossible", il suffit simplement de bien la construire (simple à utiliser).

[B.Moncef]

un code hors namespace ne serait-il pas équivalent à un code avec un namespace différent?

Si tu veux, sauf que le "namespace différent" serait en fait "aucun namespace", ce qui est différent.

[Yogui]

L'un des release managers de PHP 5.3 vient de faire connaître son avis :

http://marc.info/?l=php-internals&m=122068179008600&w=2

Anyways, anyone who cares should make their opinion known on this list as clear as possible by Monday (if someone is aware of a good discussion outside of internals please also let us know), so that Johannes and I can make a decision no later than Tuesday without having to feel like dictators. Personally at this point I would leave things as is for now, move to beta and hope that this also increases the number of end users testing and giving feedback. While I hope that we dont have to do big changes after going to beta, if feedback makes it necessary, we obviously have to accept it.

De son point de vue, les espaces de noms peuvent rester en l'état actuel, à savoir sans accolades et avec hiérarchie. Toutefois, si des personnes ressentent le besoin d'argumenter en faveur d'une autre proposition, ils doivent le faire avant lundi.

[Méthylbro]

et pourquoi ne pas rajouter une commande facultative du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
namespace XX::YY;
  // code ici
end namespace;

Ça reviens à mettre le code entre des accolades mais une simple ligne, pas la peine de l'endenter.

En ce qui concerne la pertinence de l'opérateur de résolution de portée (je dit ca pour kaymak), l'emploi du Paamayim Nekudotayim (::) dans la définition des espaces de nom parait logique.
De toute façon ; que mettre à la place ? Quasi tous les autres symboles sont utilisés pour déclarer des comportement bien différents.

[kaymak]

De toute façon ; que mettre à la place ? Quasi tous les autres symboles sont utilisés pour déclarer des comportement bien différents.

Voui c'est fort possible sa.
Mais l'idée est plutôt de traduire la structure dans la syntaxe.
Ce qui n'est pas réellement la cas avec ces deux points, après que ce soit le point, ou la virgule.... perso sa me passe au dessus, en PHP on utilise bien le dollar pour les variables, alors je pourrais m'accommoder j'en suis certain !

[Kennel sébastien]

Perso je trouve quand PHP les espaces de noms sont plus compliquer que dans d'autre langage genre Java et Python. Je comprend vraiment pas l'intéret d'utiliser use plus require. D'un coté on peut être content, on a maintenant des espaces de noms en PHP ce qui n'ai le cas en Ruby .

[GrandFather]

D'un coté on peut être content, on a maintenant des espaces de noms en PHP ce qui n'ai le cas en Ruby .

Si si, cela existe en Ruby, sauf qu'on utilise module plutôt que namespace (les modules servent aussi à faire du mix-in, de l'héritage multiple en quelque sorte).

Pour l'usage de ::, je suis totalement d'accord avec Méthylbro, son choix est parfaitement logique. Il est déjà utilisé pour les méthodes et membres statiques, et dans ce contexte le nom de classe qui le précède désigne bien un espace de nom (et non un objet réel).

Je suis par ailleurs pour l'usage des accolades ; la limite de portée d'un espace de nom doit être clairement définie, de préférence en utilisant l'élément de syntaxe ayant la même fonction dans le reste du langage.

[Yogui]

Salut

Pour rappel, le séparateur d'espaces de noms est choisi depuis quelques jours et il sera ajouté à PHP 5.3 dès la version alpha3 : le backslash \
cf. http://www.developpez.net/forums/d63...-enfin-choisi/

Cependant, tout n'est pas complètement défini. L'ordre de résolution des noms, en particulier, est encore sujet à débat :
http://wiki.php.net/rfc/namespaceresolution

La problématique est simple. Avant PHP 5.3, il n'y avait pas d'espaces de noms, il était donc impossible d'appeler une classe "utilisateur" avec le même nom qu'une classe "interne".
En revanche, grâce aux espaces de noms, il est possible d'avoir dans la même application :

use premier\espace\de\noms\PDO;
new PDO();

use second\espace\de\noms\PDO;
new PDO();

use \PDO;
new PDO();

Puisque les instructions "use" sont facultatives, autoload rentre en jeu. Il faut donc définir un ordre de résolution des noms, en évitant les conflits et les ambiguïtés lorsque le programmeur appelle "new PDO();" sans avoir d'instruction "use".

Avant PHP 5.3

Pour les fonctions et les constantes, rien de plus simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo maFonction();

1) Charger le symbole
2) Erreur fatale pour les fonctions ou notice pour les constantes

Pour les classes, il est possible d'utiliser l'autoloading :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new MaClasse();

1) Charger MaClasse
2) Autoload MaClasse
3) Erreur fatale

À partir de PHP 5.3

Pour les fonctions et constantes, l'avis est unanime, un seul ordre de résolution est possible pour le code suivant si le symbole maFonction n'existe ni dans l'espace de noms courant ni dans les symboles internes de PHP :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
use ns;
echo maFonction();

1) Charger ns::maFonction
2) Charger \maFonction
3) Erreur fatale pour les fonctions ou notice pour les constantes

Pour les classes toutefois, nous avons plusieurs possibilités pour le code suivant si le symbole MaClasse n'existe ni dans l'espace de noms courant ni dans les symboles internes de PHP :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
use ns;
new MaClasse();

1) Charger MaClasse
2) Autoload ns::MaClasse
3) Erreur fatale

1) Charger MaClasse
2) Autoload ns::MaClasse
3) Autoload \MaClasse
3) Erreur fatale

1) Charger MaClasse
2) Autoload \MaClasse
3) Autoload ns::MaClasse
3) Erreur fatale

Si j'ai bien suivi, actuellement c'est la 2° proposition qui est en place, mais la 1° a la faveur de nombreuses personnes.
Pour ma part, je préfère la 1° proposition, même si elle oblige l'ajout d'un certain nombre de "use \PDO; use \SimpleXmlElement;..." au début de chaque script.

Qu'en dites-vous ?

[Yogui]

Greg Beaver a encore une fois pris sur lui pour résumer la situation, à savoir :

• Les problèmes rencontrés ;
• Les solutions possibles ;
• Ses préférences.

Tout est dit ici : http://wiki.php.net/rfc/namespaceissues
Chacune des solutions proposées est viable à la fois techniquement et d'un point de vue utilisateur (= développeur PHP).

Sur la liste internals@, voici l'opinion des acteurs majeurs sur le conflit fonctions / méthodes statiques :

• Greg Beaver : Solution 2
• Marcus Börger : Solution 1
• Elizabeth M Smith : Solutions 1 et 3
• Steph Fox : Solution 3 (quoique 2 lui convient également)
• Derick Rethans : Solution 1
• Lars Strojny : Solution 3
• Christian Schneider : Solution 3
• Ben Ramsey : Solution 3
• Stanislav Malyshev : Solution 3
• Scott MacVicar : Solution 1

Qu'est-ce que vous en dites ?

[goodpz]

A posteriori, utiliser "." comme opérateur de concaténation de strings s'est avéré être un bien mauvais choix! Je fais bien sûr allusion aux namespaces de php 5.3 qui ne peuvent du coup bénéficier de "." comme opérateur de résolution.

[Yogui]

A posteriori, utiliser "." comme opérateur de concaténation de strings s'est avéré être un bien mauvais choix! Je fais bien sûr allusion aux namespaces de php 5.3 qui ne peuvent du coup bénéficier de "." comme opérateur de résolution.

Salut

Je comprends ta remarque mais un séparateur est un séparateur, rien de plus. Dans certains langages, le point a plusieurs significations ; en PHP, il n'en a qu'une. Dans certains langages, les espaces de noms utilisent le point ; dans d'autres, c'est un autre caractère ; en PHP, c'est le backslash. Il n'y a pas de bonne ou de mauvaise décision là-dedans, c'est simplement ainsi.

En réalité, il est du domaine du possible pour le PHP Group d'utiliser le point comme séparateur pour les espaces de noms, sans causer de conflit avec ses autres utilisations. Cependant, ce serait au prix de performances déplorables et d'un code source totalement unmaintenable dans le noyau du langage PHP... C'est exactement ce dont souffrent d'autres langages mais, puisque la plupart sont compilés, cela ne se ressent que par un temps de compilation (légèrement plus) élevé : le temps d'exécution des programmes n'est pas affecté. Cet aspect serait bien plus grave pour PHP (= ralentissement à chaque exécution), c'est pourquoi cette solution complexe n'est pas envisageable.

[goodpz]

Je comprends ta remarque mais un séparateur est un séparateur, rien de plus. Dans certains langages, le point a plusieurs significations ; en PHP, il n'en a qu'une. Dans certains langages, les espaces de noms utilisent le point ; dans d'autres, c'est un autre caractère ; en PHP, c'est le backslash. Il n'y a pas de bonne ou de mauvaise décision là-dedans, c'est simplement ainsi.

Faut quand même reconnaître que l'apparition et surtout l'adoption du backslash pour les namespaces a engendré des réactions de rejet parfois virulentes au sein de la communauté. Je ne pense pas qu'on aurait eu les mêmes réactions si l'opérateur "." avait pu être pleinement disponible.
En ce qui me concerne, j'utilise les namespaces de php 5.3 depuis un moment déjà (également lorsque "::" était implémenté). Je m'y suis fait rapidement, d'autant plus que j'ai suivi les débats sur la mailing internals et suis donc un minimum au courant des choix pratiques sous-jacents. Mais quand même, "." ça l'aurait mieux fait