bof... marche parfaitement... la fonction de find va retourner un objet ou null. if($object) fonctionne parfaitement, en php en tout cas ;)Citation:
Envoyé par spidermario
Version imprimable
bof... marche parfaitement... la fonction de find va retourner un objet ou null. if($object) fonctionne parfaitement, en php en tout cas ;)Citation:
Envoyé par spidermario
je ne m'etendrais pas sur l'exemple fourni par lordsephiroth car c'est juste une illustration mais pour faire suite au propos de sipdermario : j'aime pas voir des conditions telles que if ($objet) parce que ça veut rien dire.
ce n'est pas une verification propre.
Là ça verifie juste si $objet n'est pas faux (au sens 0, false ou null).
Logiquement on ne fait un if ($truc) que si $truc est un booléen.
Et encore j'ai pour habitude d'expliciter les choses : if ($truc === true)
Certes ça fonctionne en PHP... mais bon...
Ce n'est cependant pas nouveau, de nombreux langages considèrent que tout est "true" en dehors de la valeur "false" et de null.
D'ailleurs, si on comparait effectivement le test qui est fait par la machine, je suis persuadé que false est traduit par "0" et que null est également, d'une manière ou d'une autre, interprété comme un "0" (peut être car le pointeur pointe à la position zéro de la mémoire, position invalide, mais là je préfère pas me prononcer sur la véracité de la chose). Donc finalement... qu'on teste avec une syntaxe === false et qu'on s'oblige à mettre du booléen à gauche, ça me paraît un peu "faire du propre pour un compilateur qui s'en tape et qui traduira tout en sale" ;)
Je comprends cependant la remarque d'Elderion. Il est toujours bienvenu de vouloir programmer au plus (trop?) propre.
Techniquement true == null doit retournée false tout comme false == null, suivant la règle de propagation des null. http://en.wikipedia.org/wiki/NullCitation:
Ce n'est cependant pas nouveau, de nombreux langages considèrent que tout est "true" en dehors de la valeur "false" et de null.
Pour être plus claire "NULL" signifie "n'a pas de valeur" !
C'est pas pour troller, mais... c'est tout ??!
Je veux dire, PHP est un langage utilisé par des centaines de milliers de développeurs, et la seule évolution dont on parle pour la prochaine version majeure, c'est ça ?! C'est un peu ridicule quand même... c'est pas un truc comme ça qui va révolutionner le langage :?. Limite, ça valait pas la peine de le mentionner, ou alors en tout petit au milieu d'une liste de vraies évolutions...
Quand on voit la vitesse à laquelle évoluent d'autres langages (je pense en particulier à C#, mais c'est pas limitatif), en comparaison on dirait que PHP est en train de mourir...
Encore une fois, je cherche pas à lancer une polémique, mais je suis quand même un peu atterré qu'on fasse autant de cas d'une évolution aussi anecdotique. Rassurez moi, y a d'autres "vraies" nouveautés qui sont prévues quand même ?
Pour revenir au coeur du sujet : comme le faisait remarque quelqu'un plus haut, c'est très bizarre que le parser gérait pas déjà ça nativement...
+1Citation:
Je veux dire, PHP est un langage utilisé par des centaines de milliers de développeurs, et la seule évolution dont on parle pour la prochaine version majeure, c'est ça ?! C'est un peu ridicule quand même...
apparemment,c'est la faute de l'unicode ...
Je suis absolument POUR ! :ccool:
C'est un raccourcis qui semble évident et pourtant, il n'était pas possible.
Pour tout ce qui est de la compréhension du code, c'est le rôle du développeur et non du langage de programmation de rendre le code lisible.
Il y a des tas de Best Practices PHP à suivrent.
Par contre, reste à voir ce que ça va donner pour la gestion des erreurs. Si par exemple le retour n'est pas un Array mais un NULL.
En tout cas, toute initiative permettant d'ajouter des fonctionnalités à un langage est bonne a prendre. Libre à vous d'être assez intelligent pour ne l'utiliser qu'en cas de réel besoin :D
Je n'ai pas d'avis particulier sur cette proposition précise mais pour élargir le débat, comme proposé initialement, j'aimerais beaucoup que les fonctions de PHP soit "standardisées" tant en terme de nom qu'en terme d'ordre des paramètres.
Nom des fonctions avec et sans "_" :
Pourquoi a-t'on : strpos, strtolower, strlen... et str_replace, str_shuffle, str_split ?
Pourquoi a-t'on : filesize, filetype, filemtime... et file_exists, file_get_contents et file_put_contents ?
Je trouve ça stupide à l'utilisation.
Ordre des paramètres :
Le nombre de paramètre des fonctions n'est pas toujours le même, certes, mais il y a un élément récurrent presque à chaque fois, c'est l'objet sur lequel on applique la fonction, pourquoi n'est-il pas toujours à la même place ?
str_replace($search, $replace, $variable)
str_pos($variable, $debut, $fin)
On ne me fera pas croire que cette différence a un intérêt dans le langage... Par contre je veux bien croire que changer cela risque d'être extrêmement délicat... sauf à créer de nouveaux alias dans une nouvelle version du langage peut-être, à déprécier les anciens noms de fonction puis à les faire disparaître dans une version ultérieure.
C'est pas trop tot qu'on nous autorise ca...
Je ne comprends pas que ce ne fusse proposé plus tôt et ne comprends pas ceux qui ne voient pas l'intérêt de cette feature qui est présente dans de nombreux autres langages.
Ce qui est sympa c'est quand même c'est qu'entre XHP et HipHop de Facebook, l'utf-8 et le dé-référencement des tableaux sont déjà disponible... Pour certains développeurs !
Et que PHP 6 on est pas pret d'en voir le jour...
Et bah, je ne comprends pas qu'un truc aussi anecdotique et logique fasse autant débat... Même s'il y a peu de cas ou cette syntaxe et utile et justifiée, ce n'est pas une raison pour refuser sa présence parfois utile. Et comme ça a été dit, dans le même genre, ce serait bien de pouvoir chainer les constructer ($sDate = new DateTime($iTime)->format('rss')).
Et quand je vois les aberrations que certains sortent, en faisant par exemple l'amalgame entre une fonctionnalité et sa bonne utilisation ou en prenant un cas unique comme une généralité, je me dis que je ne suis pas prêt de changer d'avis sur ce que je pense du niveau moyen du développeur PHP (attention, je n'ai pas dit que tous les devs sont mauvais, loin de là)...
Et puis utiliser un isset pour vérifier si une variable définie juste au dessus est... définie... (Et si c'est pour tester si elle est nulle, même si isset retourne false si === null, un !is_null ou un !== null est plus correct, ou un !empty, tous 3 parfaitement inutiles et inutilement verbeux dans ce cas)...
Quant à ceux qui se plaignent 2-3 pages plus tôt qu'il faudrait que la déclaration des variables soit obligatoire, il est peut-être temps de passer l'error reporting à E_ALL (voire E_ALL | E_STRICT, au moins sur les nouveaux projets, ça fera de mal à personne).
Sinon comme ça a été dit juste au dessus (et comme je le lis souvent un peu partout), il serait bon qu'ils profitent de chaque version majeure (surtout vu le nombre d'années qui les séparent) pour homogénéiser les fonctions et rendre obsolète les anciennes syntaxes homogénéisées à la version précédente, parce qu'entre les strpos et str_len, les strtr et str_replace qui cumulent différence au niveau de l'underscore et inversion des paramètres, les nl2br et strtolower, les htmlentities et html_entity_decode, et j'en passe des dizaines, PHP continue a trainer ses débuts amateurs et ne fait pas grand chose pour améliorer la chose... Certes on est habitué, mais ce n'est pas une raison.
Même si PHP a ses défaut, la plupart des griefs que je vois à son encontre sont plus des problèmes de dev, ces problèmes venant souvent d'une mauvaise utilisation de certaines fonctionnalités ou de la méconnaissance de certaines subtilités du langage, comme les comparaisons strictes ===, combien je vois de != "" ou != 0 totalement inutiles dans le code, ou encore la méconnaissance du fonctionnement précis de certaines fonctions, les cas ou isset, empty ou is_null retournent true ou false, ou gueulent si la variable n'est pas définie (j'ai appris à la plupart de mes collègues qui dev pour certains depuis pas mal d'années pourquoi ça m'énervait de voir partout dans le code des if (isset($var) && !empty($var)), pourtant un bon dev, quand il sait pas précisément comment ça réagit, il est supposé être pointilleux, ou du moins curieux, et donc tester pour vérifier plutôt que passe des années à avoir une pratique basé sur sa méconnaissance...).
Bon, post un peu sec, le prenez pas mal, surement l'agacement d'avoir passé la journée à bosser seul sur la migration d'une énorme appli d'EZC vers Doctrine (ça lobotomise et fatigue), mais aussi à voir toutes les horreurs qui trainent dans le code (et pas que dans le vieux code historique)... J'ai vraiment du mal avec les autres dev, d'une manière générale, les devs consciencieux, voire pointilleux, se faisant tellement rares, et étant moi même à l'opposé un psychopathe qui a envi de taper sur un dev parce qu'il n'est pas foutu d'indenter correctement un tableau, de réutiliser une méthode existante ou de respecter un bout de syntaxe... Et quand ils ne peuvent pas s'empêcher de caser du français, du franglais ou de l'anglais mal traduit dans le code ou pire, dans la structure de la bdd, ce qui arrive environ 26 fois par jour, j'ai envi de les torturer à la petite cuillère...
[EDIT] Au rayon du manque d'homogénéité, j'avais oublié le isset/is_null, si bien que j'ai casé du isnull (petite inattention...) partout dans le post. A ma décharge, je ne l'utilise jamais, je préfère === null, cohérent avec === false et === true (pas de is_false ou is_true). Certains pourront dire que null est aussi un type, donc que c'est cohérent avec is_array, is_object, is_int, is_bool... Mais ceux-la, je les proute fortement :)
Chainer les constructeur c'est caca , le constructeur renvoie une référence... Et c'est mieux ainsi :)
Ca aussi ca ne devrait pas faire débat :mouarf::mouarf:
Moi ça m'intéresse car ça m'arrive de faire :
Je transforme donc le tableau en objet stdClass ((object) $montableau) juste pour faire un echo en une seule ligne (particulièrement dans mes vues d'un modèle MVC).Code:
2<?= $document->getInfos('foo', 'bar')->size ?>
hors si je pourrais faire cette méthode (même si je préfère quand même la première), ça m'arrangerait (par exemple pour la récupération des valeurs dans un tableau avec la fonction pathinfo() ) :
bref ça me sera toujours très pratique dans mes vues rien que pour ça :Code:
2
3
Code:
2<?= $album->getArticles('foo', 'bar')[2]->name ?>
Avant d'inventer de nouvelles fonctions, pourquoi ne pas commencer déjà à faire en sorte que les fonctions mathématiques soient utilisables en l'état. Venant d'un langage plus formel, les 'prouesses' de calcul de php sont vraiment déroutantes...
Certes le stockage d'un nombre flottant est connu sur tous les systèmes mais il semble que php batte tous les records...
Champagne à celui (celle) qui réussit à faire 100 factures sans erreur d'arrondi. Pourtant deux décimales c'est pas le bout du monde, mais la fonction round() est fausse (version 5.2.9.2, peut-être est-ce maintenant corrigé).
C'est vraiment agaçant de 'bidouiller' les fonctions (ou les tests de comparaison) pour être sûr d'obtenir le bon résultat.
Bien sûr il reste les biblios mathématiques, mais pas essayé. Il y a assez de morceaux comme çà à assembler (php,js,sql,...)
La multiplication des fonctions n'a jamais été pour moi une qualité d'un langage. Je dirai même que je m'emploie à n'utiliser que le minimum de commandes ou fonctions.
"La perfection c'est quand il n'y a plus rien à enlever". St Exépury, qui a réussit à traverser l'atlantique sans ordinateur.
C'est vraiment un point qui m'ennuie aussi dans PHP, l'uniformisation de la syntaxe des fonctions natives. On dirait qu'en plus, ils l'ont bien fait exprès et que ca touche toujours les fonctions associées aux String...Citation:
Envoyé par McBenny
D'autant qu'aucun réel débogueur à la volée ne viendra te dire que t'as oublié un '_' à part quand tu lanceras ton script.
J'approuve cette modif de syntaxe toutefois. Maintenant qu'ils ont passé 6 ans à la coder, faudrait peut-être qu'ils nous fassent une lib. SOAP digne de ce nom :aie:
Certes, mais php a plein de fonctions sympa, en particulier pour le parsing de chaînes.Citation:
Envoyé par aeocaeoc
Je n'ai jamais rencontré de problèmes avec round. Aurais-tu un exemple svp, ça m'interesse ?
Au risque de passer pour une énorme crasse indigne de ces forum je profite de cette opportunité d'eclaircissement sur if((isset($var) && (!empty($var)) : je n'ai pas saisi l'alternative "propre" dans le post plus haut ?
Sur la fonction objet de cette discussion, quelqu'un sait-il de manière certaine si foreach(mafonction($var) as $key => $value){...} provoque l'exécution de la fonction en boucle (si je m'exprime bien ?) et dans ce cas, c'est un peu risqué en termes de ressources (surtout que $var pourrait changer à chaque itération ?).
Aussi, cela veut il dire qu'à terme on pourrait voir se confondre les ressources (retours requêtes) et les tableaux ?
Merci de rester poli dans vos réponses :D
J'aime bien le concept mais la syntaxe me parait pas très hergonomique
Très pratique, et permet de ganger plus de temps :ccool:
Hello,
c’est vrai que c’est marrant de voir tout le tollé que génère une simple homogénéisation de la syntaxe…
Je me fais un peu l’avocat du diable en disant ça, mais pour moi qui aime énormément JavaScript, le fait que PHP s’en rapproche ne peut être qu’une bonne chose !
Après, il est vrai que quand on conçoit un langage, on a un objectif. Selon moi, un bon langage est un langage qui a réussi à se tenir à ses objectifs, ses idiomes, en mûrissant. De ce point de vue, PHP n’est peut-être pas un bon langage… Mais je l’aime bien quand même :D
Et bien empty ne génère pas plus de notice que isset si une variable n'est pas définie, donc le isset est inutile. C'est un peu comme faire un if ($var != 0 && $var == 1).Citation:
Envoyé par Perplexe
Ca fait plusieurs personnes qui parlent de "foreach(func() as $key => $val)", je ne vois pas le rapport avec ce topic, vous ne voulez pas plutôt parler de "foreach(func()[0] as $key => $val)" ?Citation:
Envoyé par Perplexe
Pour "foreach(func() as $key => $val)", la boucle se fait sur la valeur retournée par la fonction, qui n'est exécutée qu'une fois, et pour "foreach(func()[0] as $key => $val)", même chose, la boucle se fait sur la valeur de la clé 0 du tableau retourné, qui doit donc elle même être un tableau, et la fonction est donc là aussi exécutée une seule fois.
Et dans les 2 cas, si ta fonction prend un paramètre, modifier ce paramètre dans la boucle ne changera rien, puisque la fonction est appelée avant la boucle, qui se fait ensuite sur le résultat de cet appel.