Les espaces de noms en PHP 5.3 [Débat]

[GrandFather]

Envoyé par Yogui

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

J'espère alors qu'ils arriveront à dépasser ces difficultés techniques sans introduire de nouvel opérateur. PHP commence à marcher sur les plates-bandes de Java, et il serait dommage que sa syntaxe se complexifie là où Java dispose d'un opérateur de portée unique (le point).

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

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

Envoyé par Script 1

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

Envoyé par Script 2

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

Envoyé par Script 3

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 :

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 :

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 :

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 :

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 ?

[Grepsd]

Pour ma part j'opterai pour la première proposition qui nous oblige à développer avec une rigueur qu'on ne retrouve que très peu dans le milieu du développement en PHP(le libre en général par éxtension).

Les espaces de nom est vraiment un concept qui manquait à PHP et qui va faire son apparition pour mon plus grand bonheur.

J'attends maintenant la possibilité de typer les variables. :p

pour ma part j'attend la possibilite de compile le php, sur dans une architecture mvc ca prend son sens.

[Yogui]

Envoyé par mon_nom_est_personne

pour ma part j'attend la possibilite de compile le php, sur dans une architecture mvc ca prend son sens.

C'est déjà possible, dans une certaine mesure, avec des outils comme Zend Guard ou avec l'extension bcompiler par exemple

oui je sais mais je parler de procedure plus generalise car bcompile est encore au stade de beta (ou meme alpha) et les deux deux font plus de l'obfuscation qu'autre chose. moi je parle de bite code site .net, java, c++ enfin un truc qui boost la vitesse du php.
mais la c'est du hors sujet, les espace de nom oui, l'opperateur \ non pour une simple la raison suivant :
dans les encodage asiatique (chinois, coreen et japonais) le backslash devient par exemple pour le japonais ￥ desfois ca passe mais des fois ca marche pas.
apres je sais que php 6 sera en unicode mais d'ici la...
faites des tests, creer un script en jsis vous allez vous; c'est désopilant.

[Yogui]

Envoyé par mon_nom_est_personne

dans les encodage asiatique (chinois, coreen et japonais) le backslash devient par exemple pour le japonais ￥ desfois ca passe mais des fois ca marche pas.
apres je sais que php 6 sera en unicode mais d'ici la...
faites des tests, creer un script en jsis vous allez vous; c'est désopilant.

C'est intéressant
Crois-tu que tu pourrais fournir un exemple précis ? Des scripts par exemple ?

oui attend je colle ca souvent ca arrive avec les \n qui sont traite comme ¥n
ou alors le pire c'est les chemins window desfois ca marche mais desfois ca marche pas.
j'ai surtout experimente le probleme avec ma fonction mail. je fais fouiller dans ma librairie si j'ai encore un qui marche pas.

malheureusement j'en ai pas trouve, mais je souvien que j'ai eu pas mal de souci avec des \" qui, comme \ deviens￥ interprete le ".

[Yogui]

Il nous faut un exemple permettant de reproduire précisément le problème, sinon la seule explication qui me vient est que tu as probablement confondu deux encodages, bref qu'il s'agit d'une erreur de manipulation de ta part plutôt que d'un problème inhérent à PHP.

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

Envoyé par 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.

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]

Envoyé par Yogui

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