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).

[kaymak]

Moi perso sur les namespaces je n'aimais pas trop les ::.
Je trouve que c'est confusant si le code n'est pas correctement commenté j'imagine qu'au bout d'un moment on finit par plus trop savoir si on appelle une méthode static, une classe d'un namespace, une méthode dans un namespace (?je ne sais plus si c'est possible).

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).

Les accolades représentent plus q'un simple groupement de code par thème. Elles réunissent une ou plusieurs actions qui s'éexecutent dans un espace logique.
Les namespaces je voit cela comme de l'organisation, des grosses boiboite inerte, donc de mon point de vue les accolades semblent ne pas tout à fait représenter l'utilité d'un namespace.
A contrario une classe serait une boiboite, avec des pattes et tout ce qu'il faut pour se dynamiser, et donc les accolades nous disent cela.

Et sinon pourquoi pas le point ? Par curiosité.

Un truc comme cela :
nm1.nm2.classeN::methodeZ

C'est quand même sacrément plus clair à lire et écrire que
nm1::nm2::classeN::methodeZ

non ?


bye

[Yogui]

Eh bien, puisque l'opérateur de résolution de portée en PHP est officiellement le double deux-points :: depuis quelques années, je crois que personne ne l'a remis en cause

Cela dit, il est vrai qu'il risque d'y avoir confusion selon ce que tu décris, tant du point de vue interne de PHP que du point de vue de l'utilisateur. Je suis d'accord avec toi, peut-être que sur ce point il aurait été plus clair de prendre un autre résoluteur de portée. Il aurait ainsi peut-être fallu changer le nom de l'ancien résoluteur... Cela dit, le point risque de porter confusion également, dans la mesure où il est déjà utilisé pour la concaténation et où il peut donc être utilisé en combinaison avec __toString().

[mon_nom_est_personne]

qu'elle que soit la solution envisage, desole de faire mon egris, mais je vois pas l'interet a par donne un nom a quelquechose (j'espere ne pas etre le seul a faire ca) qui se fait deja.

Je creer des class static avec mes variables et mes objets pour lequelle je veux une porter global.

Code :

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

1
2
3
4
5
6
7
 
class namespace
{
public static $var1 = "lalalala";
public static $var2 = new objet();
public static $var3 = objet2::staticClass;
}

Le truc cool que je vois dans les namespaces qu'ils veulent pondre, c'est les alias, ca va rendre le code plus lisible.

Sinon un truc cool, j'y avais penser mais par manque de temps j'ai pas pu creuser l'affaire, ce serait d'avoir une representation rdf du code et d'utiliser les namespaces du rdf dans le php en guise d'alias. A l'execution d'un script le moteur mapperais les deux doc et interpreterais. Ca pourrait resoudre bien plus de probleme de porter etc... qu des "namespaces maison".

Enfin si je suis dans le tors, expliquez moi svp.

[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.

[kaymak]

qu'elle que soit la solution envisage, desole de faire mon egris, mais je vois pas l'interet a par donne un nom a quelquechose (j'espere ne pas etre le seul a faire ca) qui se fait deja.

Je creer des class static avec mes variables et mes objets pour lequelle je veux une porter global.

Code :

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

1
2
3
4
5
6
7
 
class namespace
{
public static $var1 = "lalalala";
public static $var2 = new objet();
public static $var3 = objet2::staticClass;
}

Le truc cool que je vois dans les namespaces qu'ils veulent pondre, c'est les alias, ca va rendre le code plus lisible.

Sinon un truc cool, j'y avais penser mais par manque de temps j'ai pas pu creuser l'affaire, ce serait d'avoir une representation rdf du code et d'utiliser les namespaces du rdf dans le php en guise d'alias. A l'execution d'un script le moteur mapperais les deux doc et interpreterais. Ca pourrait resoudre bien plus de probleme de porter etc... qu des "namespaces maison".

Enfin si je suis dans le tors, expliquez moi svp.

C'est pas plutot rapport aux closures sa ? de pouvoir pointer une classe, une fonction dans une variable et la manipuler ?

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

Un namespace anonyme en somme, comme le fameux type stdClass

bye

[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]

Le choix du séparateur "::" pose problème puisque cela rend confus la différence entre entre :
Classe::CONST et namespace::CONST
Classe::methodeStatique() et namespace::fonction()

Alors que sémantiquement, un espace de noms et une classe ne sont pas la même chose. En fait, c'est le nom de l'opérateur "::" qui pose problème, car avec les espaces de noms ce n'est plus l'opérateur "de portée" de PHP, du moins pas le seul. Il devrait y avoir un opérateur de portée pour les classes, et un autre pour les espaces de noms.

L'une des propositions récentes était d'avoir deux parties dans les appels à espaces de noms :

Code :

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

1
2
espace::de::noms..Classe::CONST
espace::de::noms..Classe::methodeStatique()

Cette dernière proposition me semble sympathique. Elle manque peut-être légèrement de maturité mais j'aime assez le principe d'avoir un séparateur entre le monde des espaces de noms et le monde des classes, sans pour autant modifier la sémantique de l'opérateur "::" actuel.

[Kennel sébastien]

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).

Oui ça je sais très bien ce qu'est un module et un mix-in, mais ça change rien pour l'espace de nom. T'as toujours le même problème des noms avec les requires...

[GrandFather]

Le choix du séparateur "::" pose problème puisque cela rend confus la différence entre entre :
Classe::CONST et namespace::CONST
Classe::methodeStatique() et namespace::fonction()

Cette confusion peut se présenter si dans le même code on mélange POO et programmation procédurale (fonctions définies hors d'une classe), ce qui ne devrait pas arriver dans un code bien conçu. De plus, en placant chaque classe dans un espace de nom, on annule tout risque de collision.

Les espaces de noms devraient être utilisés essentiellement pour de gros projets, ceux pour lesquels il est nécessaire d'employer des frameworks et de respecter des règles d'encapsulation (pas de variables globales, ni de fonctions définies en dehors d'une classe). Dans ce contexte, il est peu probable que ce genre d'ambiguïté se présente.

Elle manque peut-être légèrement de maturité mais j'aime assez le principe d'avoir un séparateur entre le monde des espaces de noms et le monde des classes, sans pour autant modifier la sémantique de l'opérateur "::" actuel.

Ce n'est pas l'approche adoptée par tous les langages à typage dynamique. En ruby par exemple, les espaces de nom (ou modules) apparaissent avec la même syntaxe que les classes et, si mes souvenirs sont bons, il en est de même avec Python.

[Yogui]

D'un point de vue "internals", le souci de cette confusion possible est que cela oblige PHP à définir des règles de résolution de noms très complexes ou très longues. Dans tous les cas, cela implique un ralentissement de la résolution des symboles en interne lors de l'interprétation du code. C'est là l'autre partie du débat