Discussion :

[elderion]

Cette syntaxe myFunc()[0] existe deja depuis longtemps en javascript et se révèle très pratique.
Et je ne parle la que de Javascript.
Et personne (a priori) ne s'en plaint. Alors pourquoi s'en plaindre sur PHP...

Personnellement j'approuve cette évolution du côté PHP car
c'est pénible de passer par une variable intermédiaire.

Toutefois il sera nécessaire de prévoir la gestion des erreurs si l'index dépasse la taille de la pille, etc...

[Jean Meurtrier]

Cette syntaxe existe déjà dans beaucoup d'autres langages. En C++, ce n'est que la contraction de la fonction operator[](). En fait, en passant au PHP, j'ai trouvé ça frustrant. Pour moi il doit être possible d'utiliser un retour de fonction comme n'importe quelle variable.
Pour ceux qui ont peur d'un dépassement de tableau, il devrait être possible d'intercepter une exception.

[Th3D0c]

Je dois avouer que je me suis deja retrouvé plusieurs fois a vouloir utiliser un tel syntaxe sans pouvoir le faire. Content de voir que je ne suis pas le seul ^^

Cela va nous changer la vie pour certain type de traitement comme les parsers XML ou ce genre de scripts. Apres c'est pas forcement le plus lisible de code, mais utiliser a bon escient je pense pas que cela soit problematique.

[_skip]

Je pense que c'est surtout plus cohérent niveau langage. Le fait que les expressions chaînées soient possibles sur le résultats de fonction ainsi que les opérations arithmétiques *mais pas* le déférencement me semble illogique d'un point de vue syntaxe.

[rafty]

Voir ce genre de code ne me choque plus depuis que je lis beaucoup de code JS.

Par contre, Php est-il en train de devenir le langage javascript coté serveur. Je n'ai pas dit JSP (Java Server Page).

Mais plutot JsSP (JavaScript Server Page)

[elderion]

Voir ce genre de code ne me choque plus depuis que je lit beaucoup de code JS.

Par contre, Php est-il en train de devenir le langage javascript coté serveur. Je n'ai pas dit JSP (Java Server Page).

Mais plutot JsSP (JavaScript Server Page)

Oui quand on utilise beaucoup JS, justement on se demande pourquoi cette syntaxe s'applique pas encore a PHP !

Du "JsSP" : pour ma part, ca serait pas une mauvaise chose.
Mais d'une certaine manière PHP va dans cette direction quand on voit apparaitre les fonctions anonymes, etc...

[nickyla]

Ce qui me surprend est la comparaison par beaucoup de PHP à javascript et le fait de justifier l'utilisation d'une syntaxe douteuse (niveau robustesse du code) dans PHP par son utilisation courante dans javascript
Pour moi, javascript est un langage gadget, tant par son utilité concrète que par sa syntaxe et sa structure complètement hors normes de la programmation robuste. Ce qui n'est pas le cas de PHP, au moins au sujet de son utilité (L'utilisation de ces deux langages étant particulièrement répandue dans le développement web), on voit facilement la différence quand on désactive javascript par simple click dans les options du nav, alors que PHP ... il est tout de même utilisé pour traiter des données parfois ultra-sensibles dans la plupart des sites web du monde; et celui-là pour le désactiver ...

[comode]

Plutôt pour pour ma part.

J'ai déjà regretté de ne pas pouvoir faire ça dans des cas où le doute n'est pas permis quant à la valeur de retour de la méthode.

Après, je reste inquiet pour les cas style foreach(ma_fonction() as $val) dans la mesure où je ne sais pas comment il va gérer ça. Par contre, d'un point de vu grammatical pur, je ne vois pas de raison d'interdire cette syntaxe... Je reconnais néanmoins que l'idée peut fâcher sur un langage aussi faiblement typé que PHP et sur lequel il est encore problématique de définir le type de retour d'une fonction...

[elderion]

Peut-etre considères-tu javascript comme un langage gadget par méconnaissance...?
Javascript est un langage de prototypage, dont la syntaxe diffère pas mal des langages classiques.
Quant a son inutilité : comment avec des pages HTML, veux-tu faire des interfaces riches et de l'Ajax côté client sans javascript ? Flash non parce que HTML, JSP et ASP.net utilisent du javascript (enfin il me semble)

ce que je vois de plus en plus : des interfaces client faites essentiellement en javascrpt qui invoquent des traitement et chargent du contenu auprès de services web faits en PHP (ou autre techno serveur).

Perso j'ai pas grand chose a lui reprocher si ce n'est une syntaxe un peu déroutante au départ, et que la prise en charge dans les IDE c'est pas encore ça (complétion, pointer la déclaration).
Quoique j'ai ouï dire que Aptana le fait bien.

On en vient vite a comparer PHP a javascript parce qu'on jongle de plus en plus entre les process client / serveur .

Il m'arrive meme parfois de porter des fonctions PHP en Javascript, a la maniere de phpjs.org

[elderion]

comode : charge au développeur de bien penser ses fonctions et faire attention de pas changer le type retourné du jour au lendemain.
C'est une question de rigueur.

En extrapolant, on pourrait aussi typer le return d'une méthode comme on le fait en java et .Net.
public static List geToDoList(){...}

[comode]

comode : charge au développeur de bien penser ses fonctions et faire attention de pas changer le type retourné du jour au lendemain.
C'est une question de rigueur.

Je ne dis pas, et je suis d'ailleurs pour cette syntaxe. Je modère juste mon enthousiasme car d'un point de vue grammatical, le type est implicite et n'est donc vérifier par l'interpréteur qu'au moment de l'exécution là où une fonction typé pourrait permettre une vérification dès l'analyse syntaxique (qu'elle soit faite par la machine où par l'humain à la simple lecture du code).

Bref, on est obligé d'analyser le code (ou les commentaires pour les plus rigoureux) de la fonction pour déterminer si oui où non on peut utiliser cette syntaxe alors qu'il serait quand même plus simple de regarder le type de la fonction.

[elderion]

On insiste sur le type retourné par la fonction, qu'il faut s'assurer que la fonction retourne bien un array.
certes mais c'est une problématique valable pour tout :
Si tu mets le tableau retourné par la fonction dans une variable intermédiaire, tu auras le meme probleme, car rien ne te garantit que cette variable intermédiaire contient bien le bon type de données.
Il faut se fier a la PHPDoc au dessus de la méthode (quand elle existe).
Perso je pars du principe qu'une méthode sans PHPdoc n'est pas une méthode finie.

Cette syntaxe est plutôt a considérer comme un raccourci vers le tableau direct en sortie de fonction. C'est tout en fait.

En Javascript on l'utilise et ça va tres bien
ex : document.getElementsByTagName('a')[0]
certes cette methode est native et retourne toujours un tableau
Mais si on crée une méthode JS a soi, on a la même problématique qu'en PHP.

Après ça touche aussi au débat des langages compilés et interpretés, et langages faiblement ou fortement typés.
dans le cas d'un langage typé et compilé, c'est le compilo qui fera barrage, et dans le cas d'un langage interpreté et faiblement typé comme PHP, c'est dépendant de la rigueur du développeur qui a fait ou qui met à jour la méthode.
Il faudrait alors pour PHP, expliciter le type retourné dans la signature de la méthode (je crois que je me repète la) de sorte qu'il soit figé et unique.

[Causa Sui]

et nous fournir un outil capable de gérer l'UNICODE correctement…

Étonnant… le PHP que moi je connais, il gère tous les encodages de caractères que je veux.

Ça m'énerve toujours qu'on dénigre PHP pour ça, alors qu'il contient une (des) librairie(s) de gestion des caractères 1/multi-bytes (incov, gd, etc.)
Si historiquement, il utilise un encodage de un byte par char (parce qu'il se base sur le C), il existe un équivalent multi-byte de toutes les fonctions de traitement des chaînes courante. Qui plus est, cela permet également de choisir entre l'efficacité (les fonctions mono-byte sont plus rapides) et la précision…

[bmontu]

C'est une très bonne nouvelle, absolument pas incompatible avec le typage lache de php, au contraire.
On peut deja utiliser des objets retournés pour limiter la syntaxe des variables temporaires, il ne manquait que les tableaux qui sont extrèmements courants en php!

Après php est très permissif en général et ce dereferencement pourra voire arriver du code illisible et des clés fixés en dur que je deteste (sauf la 0 a la rigueur).

Ca ne revolutionnera pas le monde, coder "propre" en php, comme dans tous les langages, demande de la rigueur au programmeur

[revlis]

Ce qui me surprend est la comparaison par beaucoup de PHP à javascript et le fait de justifier l'utilisation d'une syntaxe douteuse (niveau robustesse du code) dans PHP par son utilisation courante dans javascript

Syntaxe douteurs, c'est ton avis... D'un point de vue logique, lorsqu'une fonction retourne un objet, il parait normal d'y accéder directement...
Par exemple, ce code me parait logique et compréhensible.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class sample {
  public $attribute='test';
 
  public static function getInstance() {
    return new static();
  }
}
echo sample::getInstance()->attribute;

Mais lorsqu'elle retourne un tableau, pourquoi est ce que cela deviendrait bordélique ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
class sample {
  private $privateAttribute='test';
 
  public function getVars() {
    return get_object_vars($this);
  }
}
$sample = new sample();
echo $sample->getVars()['privateAttribute'];

je pense également a une class qu'on ne peut pas modifier (ou extention php) et qui retourne des resultats SQL sous forme de tableau, pourquoi ne pourrions nous pas écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$count = $instance->fetchRow("SELECT count(*) as nb FROM ma_table")['nb'];

Pourquoi devrions nous impérativement passer par une variable intermédiaire ?
Ou encore un code tout con comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$provider= explode('@', $emailChecked)[1];

Sans être obligé de faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

list(, $provider) = explode('@', $email);

qui pour le coup ne me parait vraiment pas propre


Cela dit, il ne faut pas non plus faire n'importe, comme appeler la fonction en boucle dans un for ou un while. Ce n'est pas la méthode magique qui va remplacer le monde, mais a partir du moment où elle apporte quelque chose de nouveau, je ne vois pas pourquoi on ne devrait pas l'intégrer dans Php.

Je ne suis pas farouchement pour cette fonctionnalité, mais je ne trouve pas d'argument contre (argument plus évolué que "le stagiaire qui sait pas programmer va casser mon projet")

[r-zo]

l'argument contre c'est juste la lisibilité du code

C'est bien gentil de se faire plaisir en tant que programmeur avec des syntaxes qui combinent plein de caractères spéciaux pour coder en une ligne ce qu'on ferait en 3 ou 4, mais après si on prend 2 fois plus de temps à relire son code (ou celui d'un autre) pour comprendre ce qu'on a voulu faire il y a 6 mois, je ne vois pas l'intérêt ...

et contrairement aux interfaces fluides qui permettent de chainer les appels aux méthodes de classes, là il n'y a pas moyen d'inventer son code pour le rendre plus lisible : tu ponds des lignes illisibles.

Après chacun fait comme il lui plait, ça reste une possibilité pas une obligation. Mais je ne vois pas d'avancée dans la façon de coder du PHP

[revlis]

Toutes ces syntaxes existent déjà et je suis sur que nos projets ont au moins une de chaque sur différents éléments...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$config['database']['passsword'];
$config->database->passsword;
$config->database()->passsword();
$config['database']->passsword;
$config['database']->passsword();
$config->database['passsword'];
$config->database->passsword();
$config->database()->passsword;

ne manque plus pour compléter la liste que ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$config->database()['password'];

Prétendre que le dernier est plus sale que tous les autres c'est de la mauvaise fois... toute simplification réduit forcement la lisibilité du code, au même titre que ($condition?$returnIfTrue:$returnIfFalse) et pourtant, on l'utilise tous, tous les jours...

[elderion]

+1.
On peut accéder directement a la propriété ou getter d'un objet renvoyé par getInstance() alors pourquoi serait-ce différent et sujet a polémique de faire la même chose avec un accesseur [] ?
C'est la meme logique. Et c'est déja présent de façon tout aussi naturelle dans bien des langages.
c'est pas tellement une évolution du PHP, mais un facilitateur, une amélioration.
Côté lisibilité je vois pas du tout où est le problème. Au contraire.

Ma conclusion : j'attendais ca depuis longtemps, je ne peux qu'approuver, et c'est au goût de chacun de l'utiliser ou pas.

[Lordsephiroth]

C'est bien gentil de se faire plaisir en tant que programmeur avec des syntaxes qui combinent plein de caractères spéciaux pour coder en une ligne ce qu'on ferait en 3 ou 4, mais après si on prend 2 fois plus de temps à relire son code (ou celui d'un autre) pour comprendre ce qu'on a voulu faire il y a 6 mois, je ne vois pas l'intérêt ...

Parce que les fichiers de 12500 lignes c'est lisible ? L'esprit humain, en tout cas le mien (et je pense pas être le seul) a de la peine à se souvenir du morceau de code qui initialisait la variable 150 lignes plus haut...

Petit exemple pour comparaison, qui vaut ce qu'il vaut car c'est du code trop simple, mais qui illustre bien la chose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
// là je trouve mon objet
$object = maClasse::trouverParIdentifiantUnique($_GET['posted_id']);
 
// je vais tester si il existe
if($object){
 
   // si il existe, je test si le champ est présent
   if($object->monChampDeTypeTable) {
 
      // oui il y est donc je teste si y a des éléments
      if(count($object->monChampDeTypeTable)){
 
         // prendre le premier élément car c'est le seul qui m'intéresse
         $maVar = $object->monChampDeTypeTable[0];
 
         // mais je dois encore tester le type du premier élément de mon tableau
         if($maVar instanceof maClasse2){
 
            // je peux afficher mon truc
            echo $maVar->unChamp;
         }
 
 
     }
 
 
   }
}

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
$object = maClasse::trouverParIdentifiantUnique($_GET['posted_id']); // find object
if($object && $object->monChampDeTypeTable && count($object->monChampDeTypeTable) // verifications
   echo $object->monChampDeTypeTable[0]->unChamp; // affichage

J'ai un peu plus de facilité à lire le second exemple. Je déteste le code aéré. Je mets pratiquement jamais de ligne vide à part entre des blocs distincs de code. Commentaires en fin de lignes. Histoire d'avoir une bonne portion de code à la vue directe et de pas devoir scroll de haut en bas sur des centaines de lignes.

(enfin mon exemple est un peu bidon quand même)

[spidermario]

Oui, notamment parce que pour l’existence, en PHP, on utilise “isset”.