La syntaxe du PHP évolue avec la possibilité de déréférencer des tableaux : pour ou contre ?

[Idelways]

Quelle évolution de la syntaxe de PHP souhaiteriez-vous ?
Déréférencement, éviction du « dollar », tableaux sans Array ou une autre ?



PHP offre un large panel de possibilités mais sa syntaxe est relativement rigide et (pour certains) « verbeuse » comparée aux autres langages dynamiques concurrents.

Johannes Schlüter travaille sur MySQL à Oracle/Sun et fait partie de la core-team (l'équipe de développement) de PHP. Il vient de présenter sur son blog une nouveauté qui sera intégrée aux versions futures du langage (5.4 ou 6, il ne précise pas).

Il s'agit de la possibilité de déréférencer des tableaux. Comme parfois un bout de code peut en dire plus qu'un long discours, il sera possible de faire :

Code :

1
2
3
4
5
 
<?php
$func = function() { return array('a', 'b', 'c'); };
echo $func()[0]; // prints a
?>

Alors qu'avant, la déclaration d'une $variable intermédiaire était obligatoire, cette nouveautés permettra plus de flexibilité lors de la programmation objet en PHP.

L'annonce de cette fonctionnalité soulève à la fois enthousiasme et critiques dans la communauté qui semble extrêmement partagée sur cette évolution.

Votre avis nous intéresse donc sur cette question : êtes-vous pour ou contre.

Et plus généralement, quelles sont les possibilités que vous souhaiteriez voir apparaitre dans les prochaines versions de PHP ?


Sources : Blog de Johannes Schlüter

Lire aussi :

Quelle est la solution PHP la plus obscure que vous ayez utilisée ? Scripts, CMS maisons ou langages "PHP-Killer" ?

Avez-vous inventé des termes que seuls vous et votre équipe comprenez ? Drôles ou techniques, expliquez-les nous

Les rubriques (actu, forums, tutos) de Développez :

PHP
Développement WEB
Langages

[r-zo]

J'ai du mal à voir l'intérêt de cette syntaxe.

[_skip]

Juste éviter de passer par une variable temporaire.
taper

Code :

$firstChild = $parent->getChildren()[0]

Au lieu de

Code :

1
2
$maVariableQuiPollue = $parent->getChildren()[0]
$firstChild = $maVariableQuiPollue[0];

[bombseb]

Je trouve que niveau lisibilité c'est pas top moi

[dolu02]

Ça m'est déjà arrivé de râler parce que ça n'était pas possible de faire ça!
Et je ne programme qu'en PHP.

Est-ce que ça engendre d'autres problèmes? Moi je n'en vois pas.

[r-zo]

je demande juste :
et pourquoi ne pas faire en sorte que la fonction en question accepte un offset en paramètre comme on peut le faire depuis des lustres ?. on aurait

Code :

1
2
 
$var = $parent->getChildren(0);

plus clair à mon sens que de rajoute cette syntaxe, qui supprime une ligne de code, pas forcément inutile puisqu'elle rend le code plus compréhensible.

[odissey]

C'est pas tant la visibilité qui m'interpelle, pour ma part, c'est plus le fait que:
1 - Ce genre de "raccourci" incite au code brouillon
2 - Une source de bug potentielle

[Jcpan]

Envoyé par odissey

C'est pas tant la visibilité qui m'interpelle, pour ma part, c'est plus le fait que:
1 - Ce genre de "raccourci" incite au code brouillon
2 - Une source de bug potentielle

rien n'oblige à l'utiliser

[CIFQ_Drew]

Pour ma part cela semble fort interessant. Ce n'est certe pas une révolution, mais j'aime d'autant mieux cette syntaxe que l'utilisation d'une variable temporaire. Quand on sait qu'une fonction retourne un tableau j'aime bien l'utiliser immédiatement comme tel (comme lorsqu'une fonction retourne un objet).

[Causa Sui]

Envoyé par odissey

C'est pas tant la visibilité qui m'interpelle, pour ma part, c'est plus le fait que:
1 - Ce genre de "raccourci" incite au code brouillon
2 - Une source de bug potentielle

... accessoirement aussi moins de code à taper, la possibilité d’une optimisation en interne (suppression d’une référence).

J'ai encore râlé il n'y a pas une heure parce que ça n'existait pas*; et qui plus est, cette syntaxe est tout à fait logique et courante (notamment en Ruby ou en Javascript pour ne citer qu’eux).

[gilwath]

vraiment pratique quand on veut récuperer que certains élément du tableau retourné.

[Jonathan Petitcolas]

Je ne vois pas bien les problèmes que cette écriture peut engendrer ? Si quelqu'un pouvait m'éclairer là-dessus ?

Car, au contraire, cela évite de passer par une variable temporaire, et donc de faire une économie de mémoire. J'ai été très étonné que PHP n'accepte pas cette écriture il y a de cela quelques temps, écriture que je trouve... naturelle.

Par contre, le nom donné... "déréférencement de tableaux"... C'est du lourd ! ^^

[spidermario]

Je me permets de citer un commentaire sur le lien de reddit.com :

I always wondered what PHP's parser must look like if it doesn't automatically support this

Traduction :

Je me suis toujours demandé à quoi doit ressembler le parser de PHP, s’il ne gère pas automatiquement cela.

[lyrix]

Je ne vois pas du tout pourquoi trouver cette méthode "brouillon". Je la trouve très pratique et l'attends avec impatience.

[tfabien]

Envoyé par Jonathan Petitcolas

Je ne vois pas bien les problèmes que cette écriture peut engendrer ? Si quelqu'un pouvait m'éclairer là-dessus ?

Car, au contraire, cela évite de passer par une variable temporaire, et donc de faire une économie de mémoire. J'ai été très étonné que PHP n'accepte pas cette écriture il y a de cela quelques temps, écriture que je trouve... naturelle.

Par contre, le nom donné... "déréférencement de tableaux"... C'est du lourd ! ^^

Juste que la fonction n'a pas intérêt à retourner "null" ...

il est d'usage de tester le retour des fonctions avant de l'utiliser...et pour cela on a besoin d'une variable temporaire si on ne veut pas invoquer la fonction deux fois

En somme:

Code :

$firstChild = $parent->getChildren()[0]

devrait etre écrit

Code :

1
2
3
4
 
$children = $parent->getChildren();
if ($children != null)
   $firstChild = $children[0];

En outre si on n'utilise jamais que le premier element d'une liste retournée par une fonction, c'est qu'on a quelque part un probleme d'architecture....

Cela dit PHP a toujours été un langage permissif et c'est une de ses forces, dans le cadre d'un développement "script" ou on est "quasi-certain" du retour, cela reste acceptable, mais il est comme toujours necessaire de comprendre le probleme éventuel que peut poser cette confiance aveugle

[Lordsephiroth]

Très content de cette nouvelle syntaxe. Très utilisé en Javascript dans les parcours de DOM, j'y vois une facilité de langage vraiment utile. Pour ma part j'espère surtout que ce changement permettra également la syntaxe simplifiée foreach directement sur un champ de type tableau lors d'un passage à travers un __get().

Actuellement il n'est pas possible d'écrire foreach($object->table as ...) selon le type de visibilité des champs de l'objet. Je suppose que la nouvelle syntaxe devrait permettre ça.

[Lordsephiroth]

et pour cela on a besoin d'une variable temporaire si on ne veut pas invoquer la fonction deux fois

on peut très bien faire un test "count() && ..." sur le tableau. Appeler 2 fois ne pose pas de problème tant que le résultat n'est pas re-calculé et doublé dans la mémoire par le second appel. Le retour d'une table se faisant par référence, appeler 2 fois sur un champ d'objet par exemple ne me paraît pas gourmant en ressources.

Envoyé par tfabien

En outre si on n'utilise jamais que le premier element d'une liste retournée par une fonction, c'est qu'on a qqpart un probleme d'architecture....

Je pense que tu peux remplacer [0] par [i] ou [$object->var] ou nimporte quel autre appel retournant string ou integer.

[tfabien]

Envoyé par Lordsephiroth

Je pense que tu peux remplacer [0] par [i] ou [$object->var] ou nimporte quel autre appel retournant string ou integer.

Code :

1
2
3
 
for ($i=0; $i < $parent->getChildren()[$i] != null; $i++)
   print $parent->getChildren()[$i];

Combien de fois est appellée la fonction getChildren?
Si derriere elle va chercher les données en base ca peut vite devenir un souci

D'ou

Code :

1
2
3
4
 
$children = $parent->getChildren();
for ($i=0; $children != null && $children[$i] != null; $i++)
   print $children[$i];

Dans un cadre clef->valeur ca peut etre plus interessant/acceptable effectivement

[Lordsephiroth]

Envoyé par tfabien

Si derriere elle va chercher les données en base ca peut vite devenir un souci

En fait je me focalise sur mon exemple de la syntaxe foreach() pour un champ d'objet private ou protected retourné par __get(). Cette syntaxe m'a toujours cruellement manqué et comme __get() retourne juste par référence un champ d'objet de type tableau, il n'y a pas de soucis à le faire.

Gaffe à l'appel de base de données en effet.

Edit : j'avoue que je n'ai pas la moindre idée si le changement de syntaxe permettra la syntaxe simplifiée foreach() pour les champs protected ou private, mais je suppose que c'est lié... le foreach doit bien être traduit par un for standard avec un appel [i] en pré-processing...

[dolu02]

Envoyé par Lordsephiroth

Actuellement il n'est pas possible d'écrire foreach($object->table as ...) selon le type de visibilité des champs de l'objet. Je suppose que la nouvelle syntaxe devrait permettre ça.

C'est plutôt logique de ne pas pouvoir accéder directement à une propriété d'object si elle est en protected ou private.
Et je ne vois pas en quoi cette nouvelle syntaxe changerait la donne
!?