Discussion :

[GanYoshi]

Je trouve ça hallucinant d'accéder à un tableau sans tester sa taille et le fait qu'il soit non null...

[Lordsephiroth]

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
!?

Sisi, tu la mets protected, mais dans le __get() tu la retournes quand même. Le protected sert à obliger l'appelant de passer au travers de __get() ou tu peux faire certains traitement additionnel.

[octal]

je pense que la fondation qui s'occupe de faire évoluer PHP devrait plutôt s'occuper à normaliser le langage et nous fournir un outil capable de gérer l'UNICODE correctement plutôt que de pourrir le langage avec des constructions aussi stupides que inutiles.

[dolu02]

je pense que la fondation qui s'occupe de faire évoluer PHP devrait plutôt s'occuper à normaliser le langage et nous fournir un outil capable de gérer l'UNICODE correctement plutôt que de pourrir le langage avec des constructions aussi stupides que inutiles.

Il vient de présenter sur son blog une nouveauté qui sera intégrée aux versions futures du langage

Ce n'est qu'une nouveauté parmi d'autres...

[10-nice]

visuellement ça choque quand même un peu. Sachant qu'on peut déjà lancer des fonctions d'objet qui serait lui même un résultat d'une fonction d'un objet parent... un exemple :

Code :

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

$barofsubfoo = $foo->functionToGetSubFoo()->functionOfSubFoo()

Mais tout développeur sait qu'il ne faut pas rester fixé sur une méthode de dev s'il y a possibilité de faire mieux/propre/optimisé, donc si cette méthode permet moins d'utilisation mémoire et une charge serveur moins importante alors pourquoi pas, au pire ça sera plus rigolo à débugger

[gilwath]

Personnellement appeler une fonction d'un objet issu d'un retour d'une fonction ne m'a jamais choqué, après faut qu'en amont ça soit bien codé pour être sur que telles fonctions renvoient systématiquement tels objets.

[Jcpan]

Code :

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

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 :

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

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

euh si tu veux faire du n'importe c'est pas le langage qui va t'empêcher

[gilwath]

De toute façon que le langage sois permissif ou pas, si tu veux sortir des aberration tu peux toujours.

[pokap]

Je suis absolument pas opposé à ce genre de nouveauté, surtout que j'ai déjà plusieurs fois essayé de faire ce genre de chose, quand on passe du JS à PHP ^^
Et pis personnellement j'attends surtout du PHP Full POO, où on n'aurait des chaînes de caractères traitable comme des tableaux, etc.

Au moins on pourra faire du :

Code :

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

1
2
3
4
5
 
$func = function() { return new Array('a', 'b', 'c'); };
 
for( $i = 0; $i < $func()->length; $i++ )
  echo $func()[$i];

[10-nice]

Je trouve ça hallucinant d'accéder à un tableau sans tester sa taille et le fait qu'il soit non null...

Ca ne m'avait même pas effleuré l'esprit mais je suis complétement d'accord. C'est une prise de risque même si le dev est sûr de son code.

Et s'il faut tester un tableau avant de l'utiliser il finira indubitablement dans une variable (à moins d'appeler deux fois de suite la même fonction qui renverra le même résultat... mais faudra voir à changer de métier dans ce cas).

Donc fonctionnalité complétement inutile...

edit: sauf en cas de stockage en $GLOBALS lors du premier rappel ^^

[revlis]

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 :

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

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

devrait etre écrit

Code :

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

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

Ton code plante aussi lorsque la fonction retourne un objet et non un array()
Il est d'usage de savoir ce que retourne une fonction avant de vouloir l'utiliser.
getChildrens pourrait systématiquement retourner un array() (vide quand il n'y a rien)...


personnellement, j'aimerais que cela soit porté aussi aux constructeurs, je trouve que le code suivant :

Code :

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

$items[] = (new Item())->setId(123)->setName('hello');

plus lisible que :

Code :

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

1
2
3
$item = new Item();
$item->setId(123)->setName('hello');
$items[] = $item;

[bubulemaster]

je pense que la fondation qui s'occupe de faire évoluer PHP devrait plutôt s'occuper à normaliser le langage et nous fournir un outil capable de gérer l'UNICODE correctement plutôt que de pourrir le langage avec des constructions aussi stupides que inutiles.

+1

[Onlava]

Moi je préfère voir le problème dans l'autre sens : Pourquoi devrait-on se passer de cette fonctionnalité ?


- Car cela fait du code "pas propre"?
Faux, on sait tous que du code pas propre si on en veut, on en fait.

- Car cela peut provoquer des erreurs d'accès au tableau ?
Faux, c'est pareil avec les variables.

- Car cela obligerait tout le monde a l'utiliser ?
Faux, la méthode actuelle reste valide.


Le calcul est vite fait..

[X0000]

La question étant :
Quelle évolution de la syntaxe de PHP souhaiteriez-vous ?

Perso je trouve le PHP trop permissif (surtout venant de C++).
Pourquoi pas faire comme en VB une option imposant la déclaration des variables avant toute utilisation, évitant le bug classique d'erreur de frappe du genre Mavariable et MaVariable.
Imposer le typage de variable lors de sa déclaration ... un des fondement en programmation non ?

[elaps]

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

On peut faire un switch.

[Dimitri S.]

La question étant :
Quelle évolution de la syntaxe de PHP souhaiteriez-vous ?

Perso je trouve le PHP trop permissif (surtout venant de C++).
Pourquoi pas faire comme en VB une option imposant la déclaration des variables avant toute utilisation, évitant le bug classique d'erreur de frappe du genre Mavariable et MaVariable.
Imposer le typage de variable lors de sa déclaration ... un des fondement en programmation non ?

+1

J'ai programmé en Java et en VB et pour ma part, je trouve que l'obligation de la déclaration des variables est un fondement de la programmation (et une fois l'habitude prise, ce n'est pas si contraignant que cela). de plus, comme c'est dis plus haut, la possibilité d'obliger la déclaration des variables (voir leur initialisation) ne serait pas gênant, puisque facultatif.

Pour ce qui est de la nouvelle fonctionnalité, pourquoi pas? Moi je ne l'utiliserais pas dans tout les cas car cela va à l'encontre des bonnes pratiques que je me suis fixées, mais si cela plait à d'autre pourquoi pas?

[Babaôrom]

C'est marrant mais c'est un truc qui m'emmerdait depuis hier, où naturellement j'écrivais comme ça et ........ euh ça marchait pas!

Je ne vois pas vraiment pourquoi on empêcherait de faire ça, la valeur de retour de ma fonction est un tableau, pourquoi est-ce que je ne peux pas directement travailler sur ce tableau, pourquoi dois-je passer par une variable intermédiaire?

Quand ma fonction me renvoie un objet, je peux bien directement à la fin de la fonction enchainer une méthode qui agit sur la valeur de retour.
Quand on me renvoie un entier, je peux aussi l'utiliser directement au milieu d'une addition.
Pourquoi le cas des tableaux est-il différent?

[Lordsephiroth]

Ca me fait bien marrer les remarques "PHP est trop permissif", alors que les grosses critiques qui ont été faites à l'encontre de langages lourds de POO (et dans cette catégorie Java reçoit la palme), c'est la "verbosité"... il faut 100 lignes de Java pour faire 5 lignes de Ruby...

Alors oui, c'est pas pareil de programmer en PHP et en Java... et après ? Les langages ne sont pas censés être tous exactement les mêmes. Sinon la vie de programmeur serait bien triste

Je code professionnellement en .NET, Java et PHP, et j'aime ces trois langages pour des raisons différentes. A chaque ses forces et faiblesses

[r-zo]

sauf qu'ajouter à PHP un mode "strict" de déclaration de variable comme décrit par Dimitri S., mode activable ou désactivable (pour garder la compatibilité avec les projets actuels) ne rajouterait pas tant de verbosité que cela.

[davcha]

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.

La quantité de mémoire utilisée n'est pas proportionnelle au nombre de variables dans ton code.

Quand tu fais un

Code :

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

$item = getMyArray()[i];

getMyArray() te renvoie, de toute façon, un tableau complet, et tu récupères ensuite le ième élément.
Si ton tableau comporte 1000 entrées, tu l'utilises à 0.1%... 99.9% de généré pour rien donc.

C'est clair que ça te permet d'optimiser ton code...