Affichage des résultats du sondage: Comment voyez-vous les espaces de noms en PHP ?

Votants
20. Vous ne pouvez pas participer à ce sondage.
  • Syntaxe actuelle (sans accolades)

    8 40,00%
  • Syntaxe de la RFC (avec accolades)

    14 70,00%
  • Autoriser les hiérarchies d'espaces de noms

    9 45,00%
  • Permettre le code hors d'un namespace dans le même script

    4 20,00%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 34 sur 34
  1. #21
    Expert Confirmé Sénior
    Avatar de GrandFather
    Inscrit en
    mai 2004
    Messages
    4 566
    Détails du profil
    Informations personnelles :
    Âge : 45

    Informations forums :
    Inscription : mai 2004
    Messages : 4 566
    Points : 6 909
    Points
    6 909

    Par défaut

    Citation Envoyé par Yogui Voir le message
    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).
    FAQ XML
    ------------
    « Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
    Giacomo Leopardi

  2. #22
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 719
    Points : 29 152
    Points
    29 152

    Par défaut

    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 ?

  3. #23
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 719
    Points : 29 152
    Points
    29 152

    Par défaut

    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 :
    Citation Envoyé par Script 1
    use premier\espace\de\noms\PDO;
    new PDO();
    Citation Envoyé par Script 2
    use second\espace\de\noms\PDO;
    new PDO();
    Citation 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 :
    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 :
    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 ?

  4. #24
    Membre habitué Avatar de Grepsd
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2008
    Messages
    96
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2008
    Messages : 96
    Points : 129
    Points
    129

    Par défaut

    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

  5. #25
    mon_nom_est_personne
    Invité(e)

    Par défaut

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

  6. #26
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 719
    Points : 29 152
    Points
    29 152

    Par défaut

    Citation Envoyé par mon_nom_est_personne Voir le message
    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

  7. #27
    mon_nom_est_personne
    Invité(e)

    Par défaut

    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.

  8. #28
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 719
    Points : 29 152
    Points
    29 152

    Par défaut

    Citation Envoyé par mon_nom_est_personne Voir le message
    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 ?


  9. #29
    mon_nom_est_personne
    Invité(e)

    Par défaut

    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.

  10. #30
    mon_nom_est_personne
    Invité(e)

    Par défaut

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

  11. #31
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 719
    Points : 29 152
    Points
    29 152

    Par défaut

    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.

  12. #32
    Membre expérimenté Avatar de goodpz
    Inscrit en
    février 2007
    Messages
    475
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 475
    Points : 531
    Points
    531

    Par défaut

    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.

  13. #33
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 719
    Points : 29 152
    Points
    29 152

    Par défaut

    Citation Envoyé par goodpz Voir le message
    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.

  14. #34
    Membre expérimenté Avatar de goodpz
    Inscrit en
    février 2007
    Messages
    475
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 475
    Points : 531
    Points
    531

    Par défaut

    Citation Envoyé par Yogui Voir le message
    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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •