Discussion :

[berceker united]

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 ?

Oui pour les classes il est possible de le typer. Soit une classe, array mais int et string ne passe pas.

[pimpmyride]

oui je suis d'accord mais les lois servent a éviter les débordements.
Un langage plus rigoureux éviterait cette discussion sur les tableaux qui me semble inutile

[kaymak]

Moi je suis contre. La communauté de dév PHP c'est un peu tout et.... le pire comme le meilleur.
Donc désolé pour les plus rigoureux d'entre nous, mais je pense qu'il serait de bon ton que de commencer à donner de vrais outils pour cadrer les développement dans ce langage. Et ce n'est pas en rajoutant n syntaxes que l'on ira dans ce sens.

Cela sans dire que de toute manière je préfererais que array() deviennent explicitement un alias de new ArrayObject();. Et non un doublon.

Perso, quitte à pinailler syntaxe, je préfererais qu'il nous demande notre avis sur les futurs espaces de noms qui utiliseront les ::. tient c'est bizarre cela me dit rappelle quelque chose... Ne serait pas confusant dans un langage aussi faiblement typé ?

bye

[stfm]

Bonjour,

la syntaxe avec les crochets me gène. Jusque là, ils étaient utilisés pour accéder aux clés et non aux valeurs, j'ai peur de la confusion que ça peut engendrer et des erreurs qui en découleront.

Les accolades me semblent aussi plus naturelles, mais il est vrai que je viens du C...

Stf

[artotal]

j'aime cette syntaxe
int [] = {1,2,3,4,5,6};
mais c'est du java

[berceker united]

Il y a pas d'histoire que ça soit plus logique ou non. Il est pas bon pour un langage de changer en cour de route. Comme je l'ai déjà précisé, ce genre de détail n'a réellement pas d'importance. PHP souffre déjà de pas mal clone de fonctions c'est pas pour ajouter encore des doublons.
S'ils veulent faire du ménage il devrait le faire sur d'autre domaine là ou c'est bien utile.

[Teoftene]

Il est vrai que la force de PHP est de permettre de mettre ce que l'on veut à tout moment dans une variable (très pratique lorsque l'on veut tester des scripts de façon brutale )

Maintenant, pour les tableaux, il est bon d'apporter un peu de rigueur ...

Si au final : $tbl[4] et $tbl{4} donne la même chose cela permet de faire à sa préférence mais dans ce cas, il est vrai qu'il faut permettre de laisser sa préférence être maître sur toute la façon de coder et donc d'autoriser aussi bien les [] que les {}

Aussi, je serai partisan d'une déclaration d'un tableau de ce type :
$tbl = array; //Pour la déclaration standard d'un tableau ouvert
$tbl = array(4); //Si l'on veut spécifier le nombre maximum d'occurrences
$tbl = array(4,2); //Si l'on veut spécifier le nombre maximum d'occurrences en multi-dimensions
$tbl = array[1,2][3,4]; //Si l'on souhaite spécifier directement des données et de ce fait exprimer la double entrée ou non
$tbl = [1,2][3,4]; //Idem que la précédente mais rendant le code moins lisible à l'humain, car la coloration syntaxique ne pourrait pas mettre en avant le typage array;

En somme, je préfère prendre un quart de seconde en plus à coder ma déclaration plutôt que d'avoir un code qui me donne l'impression de lire du brai

[Yogui]

Aussi, je serai partisan d'une déclaration d'un tableau de ce type :
$tbl = array; //Pour la déclaration standard d'un tableau ouvert
$tbl = array(4); //Si l'on veut spécifier le nombre maximum d'occurrences
$tbl = array(4,2); //Si l'on veut spécifier le nombre maximum d'occurrences en multi-dimensions
$tbl = array[1,2][3,4]; //Si l'on souhaite spécifier directement des données et de ce fait exprimer la double entrée ou non
$tbl = [1,2][3,4]; //Idem que la précédente mais rendant le code moins lisible à l'humain, car la coloration syntaxique ne pourrait pas mettre en avant le typage array;

C'est malheureusement impossible, car ce serait un changement fondamental par rapport au fonctionnement actuel de PHP !
D'une part, il n'y a jamais eu et il n'y aura probablement jamais de typage fort en PHP, donc spécifier un nombre figé ou une fourchette d'éléments d'un tableau ne sera jamais possible en PHP.
D'autre part, les accolades ne fonctionnent pas pour les tableaux mais pour les chaînes. Seuls les crochets sont utilisables lorsqu'il s'agit de tableaux.

Ce que tu présentes ici est probablement valide pour un langage mais ce n'est pas adapté à PHP

[raoulchatigre]

J'ai voté 'Contre' pour les raisons concernant la confusion entre lecture et écriture.

[Herode]

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.

Pas tout à fait : array() n'est pas une déclaration de type.

En accord avec les contre à ce sujet, côté ergonomie visuelle et maintenabilité du code :
1 - en tant que marqueur visuel, array() et plus visible que les crochets. D'autant qu'il y a pas mal d'éditeurs qui mettent en gras ce genre de mots réservés, ça permet de les repérer facilement et comme le signale bercerker united : + de clarté => moins de bugs
2 - de même, moins de doublons dans les écritures => plus d'homogénéité, donc une meilleure maintenance. Raison pour laquelle je suis tout aussi peu favorable à l'utilisation des accolades.

Si PHP était un langage à typage fort, alors une construction à base de crochets, ou à la Java, serait agréable tout en évitant le problème du typage, justement. Mais PHP est un langage à typage faible : si le code ne permet pas de visualiser facilement les types affectés, on augmente les risques d'erreurs (ré-affectation ou transtypages sauvages).

Côté compilateurs, le problème est évidemment que cette nouvelle interprétation des [] étend les contextes d'interprétation de ces symboles : actuellement, ils servent
1 - d'opérateurs d'accès dans un tableau
2 - d'opérateurs d'affectation sur un tableau construit.

Si la nouvelle écriture est acceptée, une nouvelle syntaxe devra être prise en compte dans les analyseurs ce qui, je crois, risque d'induire une (légère) diminution des performances lors de l'interprétation.

D'un autre côté, cette nouvelle écriture ouvre la voie vers la possibilité d'utiliser des tableaux anonymes. Pas sûr que ce soit vraiment indispensable, je balance juste l'idée au passage dans le cadre du brainstorming.

Globalement, donc, je voterais plutôt contre même si ça ne m'empêchera pas vraiment de dormir