Évolution : syntaxe [] pour les tableaux [Débat]

[Yogui]

Bonsoir,

Depuis quelques jours, un débat fait rage sur la liste internals@lists.php.net (archives HTTP) : faut-il ou ne faut-il pas ajouter une syntaxe de construction de tableaux PHP ?
Actuellement :

Code :

$tab = array(1, 4, 8, 2);

La proposition :

Code :

$tab = [1, 4, 8, 2];

Bien sûr, cela peut donner du code très laid comme ici :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
if (1) {
    $a = [
        [
            ['a' => 1, 3],
            ($b = 3),
        ]
     ];
} else {
    $a = [
        [
            ['b' => 1, 3]
        ]
     ];
}

Mais cela permet aussi d'avoir une syntaxe :

• Qui ne porte pas à confusion avec une fonction : array() n'est pas un appel de fonction malgré les apparences ;
• Plus courte ;
• Plus proche d'autres langages (ce qui peut être un point positif ou négatif).

Dans tous les cas, la syntaxe actuelle array() ne sera pas abandonnée, la nouvelle syntaxe sera donc un ajout. Le patch est visiblement prêt, mais le débat tourne simplement autour de "doit-on ou pas ?"


Antonio Touriño propose cet exemple :

Code :

1
2
3
4
5
// Seems more natural to me.
$array1 = ['a' => 1, 'b' => 2];
 
// than a function call...
$array2 = array("a" => 1, "b" => 2);

Max Antonov propose un contre exemple très bien senti, prouvant que la nouvelle syntaxe ne sera ni mieux ni moins bien lisible, mais simplement une alternative :

Code :

1
2
3
4
//is this a good-readable code? 
foo (array('a'=2,'b'=>array('x'=>5,'c'=>array(1,4,2)),'n'=>$bar[4])); 
//what difference in? 
foo (['a'=2,'b'=>['x'=>5,'c'=>[1,4,2]],'n'=>$bar[4]]);

Quelques têtes connues de PHP ne semblent pas être du même avis :

• Les "-1" :
  • Ilia Alshanetsky
  • Pierre
  • Arnold Daniels
  • Derick Rethans
  • Steph Fox
  • ...

• Les "+1" :
  • Elisabeth Smith
  • Rasmus Lerdorf
  • Andi Gutmans
  • ...

Qu'en pensez-vous ?

PS : Ce n'est pas la première fois que ce débat apparaît dans la liste, mais cette fois un vote semble s'organiser.

[Yoshio]

Je ne vois pas trop l'intérêt de cette syntaxe, surtout qu'au vu des exemples que tu as montré ça n'apporte strictement rien à la lisibilité du code.

Au moins aund on utilise le array() on voit directement si on a un tableau a plusieur dimension ou pas.

Puis pourquoi utiliser [] ?
Pourquoi ne pas reprendre la syntaxe du C avec des accolades ?
Par exemple :

Code :

int matrice[2][3] = { { 1 , 2 , 3 } , { 4 , 5 , 6 } };

Enfin même si il y avait une nouvelle syntaxe étant habitué à faire avec des array() je doute fort changer et c'est probablement vrai pour d'autre aussi.

[Mogwaï]

Pour ma part, j'ai voté "sans avis".

Pourquoi ? Parce qu'en effet, array() ressemble plus à un appel de fonction, que les crochets me semblent raccourcir le code sans affecter la lisibilité, mais que l'habitude poussera beaucoup de développeurs à préférer l'utilisation de array().

Au final, et puisque les 2 écritures devraient cohabiter, ça ne changera pas les choses de façon fondamentale. N'étant ni absolument pour, ni absolument contre, je suis "au milieu"

[mathieu]

J'ai voté "pour".
Étant donné que l'ancienne syntaxe n'est pas abandonnée, il vaut mieux laissé le choix aux développeurs. Ainsi dans quelque années on pourra voir "sur le terrain" l'utilisation qui en est faite et peut-être qu'avec PHP 8, une des 2 syntaxes sera supprimées.

[Eric93]

Je vote pour à 100%

[RideKick]

Sans avis aussi ... ça ne va pas changer la face du monde , les developpeurs PHP ayant pris une habitude (vous savez ce qu'on dit sur les habitudes) , la nouvelle syntaxe risque peut etre de ne jamais servir , les nouveaux developpeurs eux vont peut etre s'y mettre mais en tout cas ce n'est pas une revolution (dans mon petit monde en tou cas !)

[Gats]

j'ai voté sans avis ... comme beaucoup l'ont déjà fait remarqué cela ne va pas apporter de grand changement... puis cela fera plaisir au capitaine Crochet

[Yogui]

Ce qui serait intéressant, serait d'avoir l'avis des "contre"

Je suis plutôt pour (dsl Yogui ), mais comme le disait Yoshio, une syntaxe avec des accolades comme en C ou Java serait beaucoup mieux !

[Yogui]

Les accolades ont déjà une signification pour les chaînes en PHP : $string{4} représente le 5° caractère
En revanche, les crochets ont toujours été exclusivement pour les tableaux.

[berceker united]

Envoyé par mathieu

J'ai voté "pour".
Étant donné que l'ancienne syntaxe n'est pas abandonnée, il vaut mieux laissé le choix aux développeurs. Ainsi dans quelque années on pourra voir "sur le terrain" l'utilisation qui en est faite et peut-être qu'avec PHP 8, une des 2 syntaxes sera supprimées.

Je suis contre, l'un des problèmes de PHP c'est qu'il y a trop de fonction en double, de synthaxe différente pour un même résultat. Là, il nous propose encore une autre. Le risque c'est que si dans une application codé par plusieurs personne, pas forcément en même temps. Nous risquons d'augmenter le risque de la non homogénéité dans l'application. Si une personne à garder une habitude de syntaxe il y en aura toujours un pour aller frimer pour faire dans une autre.

Croyez moi, nous sommes vendredi soir, il est 18h30. Il y a une mise en production, le client attend. Damned il y a un bug qui apparait lorsqu'il est posé sur le serveur du client. Vite!... il faut chercher le bug. Le responsable qui pige wallou au PHP est juste derrière vous en train de regarder, vous sentez ça respiration. Le mec qui a développé cette partie s'est barré à 16h30.
Vous cherchez, vous cherchez, vous cherchez, vous comprenez pas. En fait, au bout d'une heure, vous vous apercevez que l'erreur vient d'une petite particularité rarement utilisé et le bug s'y trouvait dedans. Mais votre oeil ne l'a pas vu. Là vous modissez le développeur ainsi que toute ça famille sur plusieurs génération. Il vous a coller un piège à ours dans son code. Tous parce qu'il a coller une synthaxe de merde qui n'apporte rien de spécial à l'application et comme par hasard l'erreur était caché dedans.

Qui n'a jamais vécus ce genre de situation ? Voila ce qui risque d'arriver si nous rajoutons encore des doublons.
La meilleurs arme contre les surprises de mise en prod le vendredi soir c'est la clareté d'un code. Il faut que ça soit de la Vitell.

[berceker united]

Envoyé par Yogui

Les accolades ont déjà une signification pour les chaînes en PHP : $string{4} représente le 5° caractère
En revanche, les crochets ont toujours été exclusivement pour les tableaux.

Attention car $string[4] représente aussi le 5° caractère

[Yogui]

Envoyé par berceker united

Attention car $string[4] représente aussi le 5° caractère

Tu n'as peut-être pas compris l'objet de mon message. Les accolades ont déjà une signification de scope, ainsi qu'une signification pour les strings. Ajouter une 3° signification pour les tableaux serait sans doute très très confus pour le langage.
En revanche, les crochets ont toujours été réservés exclusivement aux tableaux.

[guidav]

Je suis contre, car je pense qu'il est utile de dissocier les crochets [ ] qui servent d'identifiants de lecture (ou de push dans le cas de $foo[] = 1) des parenthèses qui servent d'identifiants d'écriture.
L'exemple de Max Antonov est assez parlant sur ce point : dans la nouvelle syntaxe

Code :

foo (['a'=2,'b'=>['x'=>5,'c'=>[1,4,2]],'n'=>$bar[4]]);

les crochets servent à la fois à définir le tableau $foo et à lire dans le tableau $bar, d'où un risque de confusion. D'ailleurs, que penser du code suivant dans ce cas (j'ai juste ajouté une virgule) :

Code :

foo (['a'=2,'b'=>['x'=>5,'c'=>[1,4,2]],'n'=>$bar,[4]]);

Une faute de frappe qui donnait une erreur de syntaxe auparavant donnerait maintenant un tableau valide, avec un élément supplémentaire

Code :

$foo[0] = array(0 => 4)

N'hésitez pas à commenter mon intervention.

[berceker united]

Envoyé par Yogui

Tu n'as peut-être pas compris l'objet de mon message. Les accolades ont déjà une signification de scope, ainsi qu'une signification pour les strings. Ajouter une 3° signification pour les tableaux serait sans doute très très confus pour le langage.
En revanche, les crochets ont toujours été réservés exclusivement aux tableaux.

En effet !

[Rakken]

D'un point de vue personnel, je n'ai jamais vraiment apprécié l'utilisation de array() pour déclarer des tableaux. Donc, j'aurai plutot tendance a être pour.
Les [ ] sont également déjà utilisé dans le cadre des tabeaux pour la lecture, donc les mettre également pour l'écriture ne me semble pas absurde.
D'un autre coté, c'est vrai que 15 manières differentes d'écrire la même chose, a terme, ca n'est pas terrible.
Bref... j'vais attendre de voir passer un ou deux autres arguments avant de voter...

[pimpmyride]

je vote contre à 100%.

Maintenant que je suis dans le monde du travail (plus à l'école donc) les scripts sur lesquels je travail sont complexes.
Bien que n'ayant que très peu travailler sur d'autres langage à l'école (vb, c, java) je trouve qu'il manque une chose crucial à la compréhension d'un code php : la déclaration des variables.
Lorsqu'on lit un script on perd du temps à savoir si la variable est un entier, une chaine, un tableau, boolean. On voit même des choses absurdes comme un entier qui passe en string ou inversement.
Je pense que le problème poser n'est qu'une solution rapide de ce problème.

Au moins, array() permet de visualiser le type de la variable, si on en vient a mettre des crochets ca va devenir encore plus illisble.

Ainsi, je proposes une obligation de déclarer/typer les variables avant leur utilisation comme dans les autres langages !

[berceker united]

Envoyé par pimpmyride

je vote contre à 100%.

Maintenant que je suis dans le monde du travail (plus à l'école donc) les scripts sur lesquels je travail sont complexes.
Bien que n'ayant que très peu travailler sur d'autres langage à l'école (vb, c, java) je trouve qu'il manque une chose crucial à la compréhension d'un code php : la déclaration des variables.
Lorsqu'on lit un script on perd du temps à savoir si la variable est un entier, une chaine, un tableau, boolean. On voit même des choses absurdes comme un entier qui passe en string ou inversement.
Je pense que le problème poser n'est qu'une solution rapide de ce problème.

Au moins, array() permet de visualiser le type de la variable, si on en vient a mettre des crochets ca va devenir encore plus illisble.

Ainsi, je proposes une obligation de déclarer/typer les variables avant leur utilisation comme dans les autres langages !

Le défaut que tu décris n'est pas un défaut lié à PHP. Si le dev passe d'un INT à un STRING c'est qu'il code comme un porc. Pour moi c'est la base de chez base.

[Eric93]

Le PHP est un langage avec un faible typage (c'est un choix), ca présente des inconvénients, mais aussi beaucoup d'avantages, il suffit d'être rigoureu et de bien coder.

Si on reste dans cette logique, je vois pas pourquoi les tableaux serait les seuls variable ou l'on doit déclarer le type, c'est pas logique.

Pour être logique moi je suis non seulement pour, mais je serais pour la suppression du array qui est sous forme de fonction, évidemment c'est pas possible à cause de l'existant, et c'est vrai que faire cohabiter 2 syntaxe c'est pas top. L'idéal aurait été de le faire dès sa création.

Le PHP présente pleins d'incohérence de ce type, normal c'est un langage ouvert.

[Rakken]

Le défaut que tu décris n'est pas un défaut lié à PHP. Si le dev passe d'un INT à un STRING c'est qu'il code comme un porc. Pour moi c'est la base de chez base.

Humm... pas tout a fait d'accord. C'est simplement une utilisation des possibilités du langage. Ca m'est arrivé de faire des concaténation de string et d'int (faisant de faire une conversion implicite de mon int en string).
Dans le genre, le pire que j'ai du faire, c'est un truc du genre "machaine-1", faire un substr pour récuperer le "1", faire un ++ et reconcaterner. Ca a l'air étrange, mais ca reste pratique. Je considère même que c'est une force du php. (Après, avoir un $tmp, y stocker du texte et trois ligne plus bas y stocker un int, c'est effectivement porc, tout dépend de l'usage qu'on fait des possibilités, encore une fois)

Plutot que de forcer absolument le typage, j'aimerai au moins qu'il puisse être optionnel. Pouvoir déclarer un string, et de fait, interdire les conversions implicite.
Il me semble que c'est déjà possible pour les classes (en parametre d'une fonction spécifier qu'elle ne prend que des variables d'une classe donnée (sur ce point précis, je ne suis pas super sur de moi, quelqu'un pour confirmer/infirmer ?)), alors pourquoi pas pour les types de base ?