Syntaxe actuelle (sans accolades)
Syntaxe de la RFC (avec accolades)
Autoriser les hiérarchies d'espaces de noms
Permettre le code hors d'un namespace dans le même script
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 :
Qu'est-ce que vous en dites ?
- 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
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 1Envoyé par Script 2Puisque 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".Envoyé par Script 3
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();Pour les classes, il est possible d'utiliser l'autoloading :1) Charger le symbole
2) Erreur fatale pour les fonctions ou notice pour les constantes
Code : Sélectionner tout - Visualiser dans une fenêtre à part new MaClasse();À partir de PHP 5.31) Charger MaClasse
2) Autoload MaClasse
3) Erreur fatale
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();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 :1) Charger ns::maFonction
2) Charger \maFonction
3) Erreur fatale pour les fonctions ou notice pour les constantes
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 fatale1) Charger MaClasse
2) Autoload ns::MaClasse
3) Autoload \MaClasse
3) Erreur fataleSi j'ai bien suivi, actuellement c'est la 2° proposition qui est en place, mais la 1° a la faveur de nombreuses personnes.1) Charger MaClasse
2) Autoload \MaClasse
3) Autoload ns::MaClasse
3) Erreur fatale
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 ?
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.
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.
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 ".
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.
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.
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager