Le langage PHP est régulièrement critiqué comme étant un langage pour mauvais programmeurs, trop laxiste et ayant des années de retard sur ce que fait Python ou encore Ruby (s'il vous plaît, ne commencez pas les comparaisons stupides en RoR et PHP...), donc bien qu'à priori, cela n'intéressera pas forcément tout le monde, le langage continue d'évoluer et, à mon humble avis, plutôt dans le bon sens.
La sortie de PHP 5.3 apporte son lot de nouveautés et de correction de bugs (une centaine de correction)
Parmi les nouveautés :
- Une meilleure gestion des méthodes et propriétés statiques avec l'ajout d'une méthode magique __callStatic() permettant la gestion de méthodes statiques non définies. Ou encore la possibilité de faire un appel à une méthode statique avec un nom de classe en variable (de ce style : $class::methode(); )
- La possibilité d'utiliser des fonctions lambda. Il était déjà possible de créer dynamiquement des fonctions avec la fonction create_function() mais ces dernières n'étaient pas prises en compte dans les système de cache d'opcode et rendaient le code moins lisible
- L'ajout des fermetures qui ajoutent aux fonctions lambda la possibilité d'utiliser des variables externes. Celle-ci sont passées, par défaut, par valeur ce qui permet de ne pas avoir de résultats indésirables (que l'on pourrait avoir avec l'utilisation d'un global)
- L'une des fonctionnalités les plus attendues : l'espace de noms. Je ne vous ferez pas l'affront de vous décrire les utilités d'un tel ajout dans le langage mais si vous ne savez ce que cela peut apporter, référez vous aux liens ci-dessous. Des critiques sont notamment apparu sur le choix du séparateur, je me garderais bien de commenter cette décision avant de l'avoir tester plus profondément.
- L'amélioration du fichier de configuration php.ini qui permet maintenant d'avoir des variables à l'intérieur de ce dernier, très utile pour éviter les redondances (ah si on pouvait avoir la même chose en CSS...). De plus il est possible d'avoir un fichier de configuration par site et/ou par utilisateur (si l'on fonctionne en CGI), très pratique pour donner plus ou moins de droits en fonction de la confiance accordée aux différents usagés de votre serveur.
- Une meilleure gestion de garbage collector qui avait quelques difficultés avec les objets ayant une relation parent-enfant.
- Certaines extensions rentre dans le cœur de PHP. C'est le cas de FileInfo (utilisé pour connaitre des informations sur les fichiers), Intl (fonctions pour le support de l'unicode), Phar (fonctions d'empaquetage de fichier et qui permettent également l'utilisation directe de fichier php à l'intérieur de l'archive), mysqlnd (remplacement de l'extension utilisé auparavant par MySQL et MySQLi) et SQLite3 (ah, enfin le support natif de la version 3, il était temps)
- L'arrivée de la constante d'erreur E_DEPRECATED qui sera renvoyé lors de l'utilisation de fonctions non supportées par la prochaine version de PHP. Parmi ces fonctions dépréciées : ereg_* que l'on conseille de remplacer par preg_* car il n'y aura plus qu'un seul moteur d'expressions régulières ou encore les magic_quotes.
- Enfin et j'ai préféré garder le meilleur pour la fin. L'instruction bien connue "goto" fait son arrivée. J'aurais pu attendre vendredi rien que pour cette instruction, mais je préfère poster mon premier journal sereinement...
Voilà, cette version de PHP intègre vraiment des choses prometteuses pour les développeurs web. Gageons qu'ils seront en tirer le meilleur.
Pour aller plus loin dans la découverte de PHP 5.3 :
Les nouveautés de PHP 5.3 (sur Developpez.com)
PHP 5.3 : Nouveautés : Introduction et Sommaire (de Pascal Martin)
# PHP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -10.
Huhu.
Blague à part, y a quoi comme véritable intérêt à PHP ?
J'ai jamais compris le goût pour ce langage sans aucune sémantique qui se contente d'empiler bug^wfeature sur feature.
[^] # Re: PHP
Posté par guppy . Évalué à 5.
[^] # Re: PHP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10.
>> Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
PHP, c'est exactement l'inverse. Y'a qu'à voir, ils mettent en avant une nouvelle méthode magique, des fonctions anonymes, des fermetures, un goto, etc, etc.
Et l'un des lien précise "ha, c'est chiant, le goto ne permet pas de sauter n'importe où", "le break ne permet pas de s'échapper de plusieurs boucles imbriquées", "le goto n'a pas de portée dynamique" et autres trucs du genre.
Ensuite le langage appelle tableau des dictionnaires ou tables de hachage.
Je cite wikipedia au passage qui dit "le nom des fonctions (ainsi que le passage des arguments) ne respecte pas toujours une logique uniforme".
Bref, toutes ces petites choses qui font la différence entre un langage pensé et développé pour et par des gens intelligents, et le reste dont PHP est selon moi l'un des "meilleurs" représentants.
Après, si t'es pas d'accord, libre à toi de coder en PHP. J'en dirai toujours du mal, car le langage mal conçu initialement ne pourra *jamais* devenir bien, alors que d'autres langages qui sont partis de bonnes bases formelles et qui évoluent tout autant se rafinent avec le temps.
[^] # Re: PHP
Posté par guppy . Évalué à 7.
[^] # Re: PHP
Posté par dyno partouzeur de drouate . Évalué à 10.
Ajoutons à cela que le langage est assez permissif et neuneu-compliant pour inciter à l'écriture de code illisible, et que la sécurité est une préoccupation qui semble avoir toujours eu une priorité basse sauf peut-être récemment, et on comprend que 99% du code PHP est buggé et souffre de failles persistantes.
Et puis tu commences à regarder l'API.
Et là tu pleures.
Je crois que je n'ai jamais vu un tel bordel. Une tétrachiée de fonctions avec des idées sympas genre:
- plusieurs fonctions font la même chose
- plusieurs fonctions se ressemblent, mais ne font pas la même chose
- plusieurs fonctions sont voisines, mais l'ordre de leurs arguments est subtilement différent
- une fonction a une fonctionnalité qui change complètement selon le nombre d'arguments qu'on lui passe.
- le nommage est aléatoire. parfois il y a un préfixe devant les noms de fonctions d'une même API, parfois pas.
- Il n'y a de toutes façons pas de convention de nommage. fonction(), api_fonction(), ApiFonction() et diverses autres conventions se mélangent allègrement.
- des fonctions non documentées
- des fonctions dons la doc (uniquement dispo en ligne, trop de la balle pour développer quand t'as pas une connexion internet) qui disent que ça marche pas
- etc, etc.
Ce langage n'est qu'un ramassis de verrues qui ont poussé sur un truc qui était à l'origine pas fait pour (Personnal Home Page que ça voulait dire PHP, c'était pas pour rien), et ça se voit. Sa seule chance a dû être de disposer d'un module Apache et d'être assez facile à utiliser pour que les hébergeurs s'y intéressent et le proposent à leur clients.
[^] # Re: PHP
Posté par fcartegnie . Évalué à 3.
Comme DOM, DomXML... bordel courant récurrent
Java avait introduit les avertissements de dépréciation dès le début. PHP a du attendre la 5.3, qui introduit pourtant des changements mineurs par rapport au passage 4->5.
Vraiment du n'importe quoi.
[^] # Re: PHP
Posté par Philippe F (site web personnel) . Évalué à 9.
Vraiment en ces périodes de crises, PHP, c'est le langage qui va vous permettre de passer à côté de la charrette.
[^] # Re: PHP
Posté par leoboy . Évalué à 3.
En plus, en Perl, on peut être encore plus crade qu'en Php.
D'ailleurs, je me demandais, si on met de côté les langages de laboratoire ( Brainfuck, Malbolge...), quel est le langage suprême en terme de cochonneries que l'on peut trouver couramment en production ?
Allez, vous êtes tous tombés un jour sur des scripts non-commentés, tordus, incompréhensibles tellement le langage utilisé permettait d'écrire en mode sale... A part Perl et Php, avez-vous de telles expériences avec d'autres langages ?
[^] # Re: PHP
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 7.
[^] # Re: PHP
Posté par Babelouest (site web personnel) . Évalué à 5.
Le C voyons
D'ailleurs comme on dit :
Le langage C combine l'efficacité de l'assembleur avec la lisibilité de l'assembleur
Sans parler du mondialement connu concours du IOCCC (International Obfuscated C Code Contest) http://www.de.ioccc.org/main.html .
Dans mon expérience, le C est un des langages qui permet de faire du code très sale, à plus forte raison quand on commence à jongler avec les macros et les différentes API qui n'ont pas la même convention de syntaxe...
[^] # Re: PHP
Posté par Gniarf . Évalué à 5.
[^] # Re: PHP
Posté par Sufflope (site web personnel) . Évalué à 5.
Mais tu aurais bien tort de ne pas le faire :o)
[^] # Re: PHP
Posté par Prae . Évalué à 4.
[^] # Re: PHP
Posté par phyce . Évalué à 5.
J'ai des exemples mais ils sont souvent assez spécifique à mon domaine...Pourtant je suis sur que tout le monde a rencontré ces horreurs :)
[^] # Re: PHP
Posté par totof2000 . Évalué à 3.
Un autre truc complêtement pourri : BladeLogic.
[^] # Re: PHP
Posté par Moogle . Évalué à 1.
[^] # Re: PHP
Posté par Brioche4012 (site web personnel) . Évalué à 4.
[^] # Re: PHP
Posté par zebra3 . Évalué à 10.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: PHP
Posté par Prae . Évalué à 1.
[^] # Re: PHP
Posté par totof2000 . Évalué à 3.
Un peu difficile au début, car le framework Rails bouge beaucoup et la documentation a parfois un peu de mal à suivre, mais une fois qu'on a compris le truc, ça va tout seul.
[^] # Re: PHP
Posté par leoboy . Évalué à 1.
Cela dit, si RoR bouge tous les 6 mois, ça doit pas être fastoche de faire de la production... ou du moins, à chaque mise à jour, ça doit être coûteux en temps de validation, de correction, etc...
Pour un petit site dynamique, ça peut encore passer, mais si l'on décide de coder une *grosse* application avec RoR, ça doit pas mal compliquer la tâche...
Vous avez des retours d'expérience là-dessus ?
[^] # Re: PHP
Posté par Laurent Cligny (site web personnel) . Évalué à 2.
[^] # Re: PHP
Posté par totof2000 . Évalué à 2.
Je n'ai pas suffisamment de recul mais il me semble également que du code écrit pour une version N de rails fonctionnera avec une versio n+x.
Le temps et l'investissement passés à l'apprendre sont largement compensés par la puissance du langage/framework.
[^] # Re: PHP
Posté par Maclag . Évalué à 3.
[^] # Re: PHP
Posté par leoboy . Évalué à 9.
[^] # Re: PHP
Posté par Thomas . Évalué à 2.
Pour faire un parallèle :
C'est à se demander pourquoi ces cons de fabricants d'ordinateurs se sont mis d'accord avec ces imbéciles de développeurs d'applications pour mettre Windows quasiment partout!Tu trouves toujours que les parts de marchés sont un argument quant à la qualité d'un produit ? :o)
[^] # Re: PHP
Posté par Maclag . Évalué à 3.
Alors pourquoi les hébergeurs qui proposent des CMS par défaut ne proposent-ils pas Zope par défaut et option PHP plutôt que le contraire?
Pour revenir sur la comparaison, c'est MS qui se met d'accord tout seul pour flinguer tout constructeur qui ne proposerait pas Windows partout et mis en valeur. Je vois pas la communauté PHP menacer les hébergeurs, et ceux qui proposent du Python ne sont pas légions.
Alors je ne dis pas que PHP c'est mieux que Python, je dis juste que si c'était si mauvais, nombreux sont ceux qui seraient passés à autre chose, non?
J'aimerais avoir des retours de développeurs de CMS sur la pertinence du "Python est vachement meilleur que PHP".
[^] # Re: PHP
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: PHP
Posté par totof2000 . Évalué à 7.
Non, c'est justement parce que c'est mauvis que c'est répandu ...
[^] # Re: PHP
Posté par totof2000 . Évalué à 1.
Ya qu'a voir la musique. En plus si on a les moyens de faire un buzz dessus, c'est gagné.
# GOTO : Nostalgie...
Posté par gUI (Mastodon) . Évalué à 3.
Je me souviens que j'ai commencé à programmer sur un MSX, en basic. Bien sur ligne numérotées, et à la toque de GOTO. Un bon code est un code à base de GOTO (-:
Quand je suis arrivé à l'IUT et qu'on a commencé à coder en Ada, ça m'a foutu un choc. Impossible d'arriver à faire quoi que ce soit avec ce fichu langage !!! Pouah !!! Manquait plus qu'on m'enseigne les fonctions et là, vraiment, j'étais largué.
Bon, évidemment, maintenant que beaucoup d'eau a coulé sous les ponts, ça me ferait vraiment tout drôle de refaire du code avec un GOTO dedans... mis à part un petit coup de nostalgie, il y a une vraie utilité au GOTO ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: GOTO : Nostalgie...
Posté par ccomb (site web personnel) . Évalué à 10.
[^] # Re: GOTO : Nostalgie...
Posté par Buf (Mastodon) . Évalué à 10.
Dans un langage avec des exceptions, par contre, j'ai vraiment du mal à voir à quoi ça sert.
[^] # Re: GOTO : Nostalgie...
Posté par windu.2b . Évalué à 3.
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 3.
Cependant, le goto est tellement banni de nos jours qu'on ne peut même plus se permettre de l'utiliser dans des cas légitimes (les gens préférent presque voir une variable à la place). Je suis d'accord qu'il ne faut pas habituer les jeunes programmeurs à y recourir systématiquement mais là, plus personne ou presque ne sait aujourd'hui pourquoi cette instruction est tant proscrite.
À dire vrai, je milite pour la rédaction un guide du bon usage du goto et pour son enseignement « propre » dans les écoles. Pour certains, n'importe quelle horreur est préférable à un goto (par exemple des exit() au beau milieu d'une procédure).
[^] # Re: GOTO : Nostalgie...
Posté par Zenitram (site web personnel) . Évalué à 5.
Heu... tu peux fournir un exemple?
Car tel que tu le dis, je fais juste un do{} while() à la place de while(){} et c'est réglé, donc je ne vois toujours pas d'utilité à goto.
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 4.
int x,y;
x=1;
y=5;
goto entree:
do
{
printf ("-");
entree:
printf ("%d",x);
}
while (x<5);
1-2-3-4-5
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 3.
[^] # Re: GOTO : Nostalgie...
Posté par campagnard . Évalué à 1.
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 10.
[^] # Re: GOTO : Nostalgie...
Posté par Babelouest (site web personnel) . Évalué à 2.
déjà comme ca, le compilo C (admettons qu'on donne ca à manger à un compilo C dans un bô main tout propre) va faire plop !
parce que c'est pas
goto entree:qu'il faut mettre maisgoto entree;ensuite si tu colles tout ca dans un beau main, ca va faire :
1-1-1-1-1-1-1-1-1-1-1-1-1-1[...]
parce qu'il faut mettre
printf("%d", x++);enfin, ca affichera 1-2-3-4 parce que
while (x<5)s'arrêtera lorsque x==5 donc pan !et peux-tu m'expliquer l'intérêt de
y=5;vu que tu t'en sers pas, mmmmmm ?Nous avons ici, mesdames et messieurs la preuve irréfutable que le GOTO est considéré comme nuisible !
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 5.
[^] # Re: GOTO : Nostalgie...
Posté par gUI (Mastodon) . Évalué à 5.
c'est vrai qu'un poil documenté (un simple commentaire "on saute le premier '-' pour afficher un chiffre d'abord") permet au code d'être parfaitement maintenable.
on ne peut pas dire que ce soit particulièrement crasseux.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: GOTO : Nostalgie...
Posté par alice . Évalué à 1.
for( int x = 1; ;++x )
{
printf "%d",x);
if( x >= 5 )
break;
printf ( " - " );
}
Tant pis pour les quotes...
[^] # Re: GOTO : Nostalgie...
Posté par gUI (Mastodon) . Évalué à 2.
Mais niveau "propreté", c'est pas génial, j'en suis à peu près aussi fan que le GOTO. Sans compter que tu passes ton temps à faire un "if" supplémentaire dans ta boucle, uniquement pour ce break. Le GOTO a l'avantage de ne pas alourdir du tout ton code (mais je suis le premier à préférer la propreté à l'efficacité pure et simple).
Et au passage le "++x" est vraiment moche, et très dangereux. De là où je viens, c'est même formellement interdit !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 3.
Par contre, je suis assez fan des pré-incrémentations, aussi. Peux-tu nous expliquer pourquoi elles sont proscrites par chez toi ?
[^] # Re: GOTO : Nostalgie...
Posté par yellowiscool . Évalué à 3.
En effet, en C++, lorsque l'on post incrémente un gros objet, le compilateur peut avoir envi de faire une grosse copie qui ne sert à rien.
Après certains optimisent, mais c'est bien de le faire directement comme il faut.
Envoyé depuis mon lapin.
[^] # Re: GOTO : Nostalgie...
Posté par gUI (Mastodon) . Évalué à 3.
"chez moi", c'est le développement logiciel embarqué avionique.
les règles sont simple : une seulke instruction par ligne. du coup ca élimine de fait le ++x ainsi que le x++. exception : la boucle for dans sa forme de base : for(i=min;i<=max;i++)
sur une seule ligne on a le droit de faire x++ (on ne nous oblige pas à faire x=x+1) (et je crois que x+=1 est interdit aussi).
le ++x est strictement interdit.
je pense que la raison de toutes ces règles est uniquement la clarté du code. les formes abrégées sont généralement proscrite, puisque le code de toute façon sera le meme, autant explicité les traitements.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: GOTO : Nostalgie...
Posté par yellowiscool . Évalué à 1.
++x, c'est:
x = x+1;
x++, c'est:
temp = x;
temp = temp +1;
x = temp;
Cette copie n'est utile que lorsque l'on passe un objet en paramètre d'une fonction, et que l'on veut qu'il soit incrémenté juste après son passage en tant que paramètre.
Et c'est justement que que tu ne dois pas faire.
Envoyé depuis mon lapin.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GOTO : Nostalgie...
Posté par lasher . Évalué à 0.
Perdu. inc et add ne sont pas toujours équivalents en termes de vitesse d'exécution (par exemple sur les processeurs de type x86).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 6.
D'une part, la lisibilité est une notion très subjective. Ça peut être justifié mais, huit fois sur dix, quand on dit qu'un code n'est pas lisible, c'est que l'on manque d'argument. Un « ++x » ni plus ni moins lisible qu'un « x++ ». C'est un peu comme polémiquer pour savoir s'il faut mettre l'accolade ouvrante « {&nsbp;» à droite ou en dessous du nom de la fonction (je la mets en dessous).
Ensuite, écrire du code d'une certaine façon en tablant sur le fait que le compilateur va l'optimiser ensuite n'est pas une raison valable à elle seule d'adopter une manière d'écrire plutôt qu'une autre. D'abord parce que ce n'est pas garanti (dépend du compilateur) et qu'ensuite, ça ne sert à rien d'écrire d'une certaine manière si l'on veut que ce soit traduit de façon complètement différente.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GOTO : Nostalgie...
Posté par yellowiscool . Évalué à 4.
Après, peut-être que tu n'incrémente pas des objets tout les jours, mais ça arrive. Et là, ce n'est plus du tout trivial.
Envoyé depuis mon lapin.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GOTO : Nostalgie...
Posté par Batchyx . Évalué à 4.
Sans parler que en C++, a++ et ++a sont deux fonctions différentes, et qu'un programmeur pourrait décider par exemple, d'implémenter un copy-on-write, et ça c'est moins évident à optimiser pour un compilateur.
[^] # Re: GOTO : Nostalgie...
Posté par yellowiscool . Évalué à 0.
Mais autant faire ce qu'il faut directement. Interdire la version qui fait directement ce qu'il faut au profit d'une autre qui nécessite une étape de plus, même si elle est supprimée par certains compilateurs, c'est étrange.
Et ton passage sur l'assembleur n'est valable que pour un certain type de variable.
Si tu veut incrémenter un objet qui est très gros (disons 150 octets, il contient du texte par exemple), c'est pas vraiment pareil.
Envoyé depuis mon lapin.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GOTO : Nostalgie...
Posté par yellowiscool . Évalué à 1.
C'est certain qu'avec gcc, tu risques pas d'avoir une grande différence. Mais après c'est encore une fois un tout petit truc où il faut faire un choix.
Ce qui change est très léger, mais est légèrement mieux.
Mais comme le compilateur fait le travail à ta place, autant faire la mauvaise solution dans ce cas là.
Envoyé depuis mon lapin.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GOTO : Nostalgie...
Posté par yellowiscool . Évalué à 2.
D'ailleurs, je viens de regarder les profils des opérateurs pour incrémenter des objets, et pour la post incrémentation, c'est :
Lol * const operator++ (int)
et dans le cas de la prés incrémentation, c'est:
Lol * const operator++ (void)
Le int en argument n'est là que pour différencier les deux fonctions, c'est pas vraiment beau.
Dans le cas de la post incrémentation, tu es censé renvoyer une copie avant modification (sinon, tu ne respecte pas les conventions de codage), et là c'est ton code. Après, le compilateur peut s'amuser à supprimer le passage où tu fais la copie, ainsi que le renvoi du pointeur, mais c'est toujours la même histoire, doit-on faire confiance au compilateur ?
Envoyé depuis mon lapin.
[^] # Re: GOTO : Nostalgie...
Posté par guppy . Évalué à 0.
Mais qu'appelles-tu une "instruction" ? C++ n'est pas assez bas-niveau (proche de la machine) pour que cette notion ait un sens. Quoique tu écrives, sur une ligne ou sur plusieurs, tu ne peux pas garantir le code machine généré. A mon avis, à part pour des cas très spécifique (peut-être que ton métier est dans ce cas ceci-dit), il faut justement laisser les considérations que tu cites de côté afin de se concentrer sur l'aspect métier du code.
[^] # Re: GOTO : Nostalgie...
Posté par Thomas Douillard . Évalué à 2.
i = prout( (bla,i++) , procedureaveceffetdebord(parametre--,&i), i ;
Genre ça doit être à peu prêt valide en C si je me trompes pas, mais pour savoir ce qui se passe ... C'est pas trivial genre.
[^] # Re: GOTO : Nostalgie...
Posté par Thomas Douillard . Évalué à 2.
Encore pire peut être :
i,j = ( prout( (bla,i++) , procedureaveceffetdebord(parametre--,&i) ), i ) , a ;
[^] # Re: GOTO : Nostalgie...
Posté par lasher . Évalué à 2.
Tu peux argumenter s'il te plaît ? De là où je viens, ++x est moins dangereux que x++, vu que l'incrémentation est d'abord faite, et que du coup, x n'est évalué qu'une fois (en C on s'en fout, en C++, ça a son importance, si x est une instance de classe et que ++ a été surchargé ...).
[^] # Re: GOTO : Nostalgie...
Posté par lasher . Évalué à 3.
Sinon, utiliser un goto pour créer un 2è point d'entrée dans une boucle n'est pas toujours une bonne idée je pense, car s'il s'agit d'un langage compilé, le compilateur va avoir beaucoup plus de mal à optimiser le code (un compilateur aime bien quand les nœuds de ses graphes sont simples à gérer). Certaines transformations optimisantes sur les boucles nécessitent que celles-ci disposent de certaines propriétés, et le goto casse tout ça. Si la boucle n'est pas souvent prise, on s'en fiche, bien sûr. Mais dans le cas contraire...
[^] # Re: GOTO : Nostalgie...
Posté par Krunch (site web personnel) . Évalué à 1.
En bidouillant un peu, il y a moyen de se faire des macros qui font des exceptions presque comme en C++ ou Java : http://adomas.org/excc/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: GOTO : Nostalgie...
Posté par ɹǝıʌıʃO . Évalué à 4.
(/me se rappelle encore avoir appris la subtile distinction entre GOTO et GOSUB…).
[^] # Re: GOTO : Nostalgie...
Posté par 2PetitsVerres . Évalué à 5.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: GOTO : Nostalgie...
Posté par Gniarf . Évalué à 4.
20 GOTO 10
[^] # Re: GOTO : Nostalgie...
Posté par Graveen . Évalué à 2.
[^] # Re: GOTO : Nostalgie...
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 3.
10 PRINT "ça fait chier les cons":GOTO 10[^] # Re: GOTO : Nostalgie...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: GOTO : Nostalgie...
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
En général c'est employé pour la gestion des erreurs (en C), ça rend le code plus clair en évitant des multiples if imbriqués.
les pixels au peuple !
[^] # Re: GOTO : Nostalgie...
Posté par IsNotGood . Évalué à 3.
La gestion d'erreur.
En C++ on fait une exception, en C un goto (ou un longjmp).
J'ai fait du code avec des goto pour gérer les erreurs (du moins en sortir), ben sans goto c'est un cauchemard.
Mais il est clair que le C++ avec les exception c'est beaucoup mieux.
[^] # Re: GOTO : Nostalgie...
Posté par Prae . Évalué à 2.
Je me souviens d'un bouquin supra utile sur l'optimisation de code;
Et le mec disait en gros « Parfois il est plus utile d'utiliser un GOTO bien placé et bien optimisé que des imbrications de if et else qui rendent votre application illisible, non-optimisée, non-optimisable et donne des codes assembleurs de 15 km » (en somme, c'est pas le langage qui fera que votre application sera optimisé mais votre code)
[^] # Re: GOTO : Nostalgie...
Posté par nicko . Évalué à 2.
En robotique, automates programmables ou encore les machines à commande numérique : (l'instruction G79 en language ISO 6983)....C'est pas des GOTO mais ça fonctionne pareil
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 5.
En même temps, moi je suis assez fan des « if » imbriqués, aussi. En fait, je trouve que l'essence même de la programmation structurée se trouve là-dedans : pouvoir identifier au niveau formel la route suivie par le code.
Je trouve ça beaucoup plus propre que de tout mettre à plat et de quitter la fonction avec un return (qui est un goto déguisé, quand il ne se trouve pas en fin de fonction) dès que quelque chose cloche. D'abord, parce que quand on élabore un processus complexe où chaque opération est dépendante de la première, il devient très difficile de déconstruire ce que l'on a fait dans les lignes précédentes si une condition vient à ne pas être remplie et qu'il faut avorter le processus, ensuite parce que la prochaine action ne peut être déterminée qu'en connaissant l'état de la machine au run-time.
À contrario, des « if » imbriqués ne sont pas si illisbles que çà, surtout s'ils sont proprement indentés : en choisissant par exemple une largeur de 4 caractères, on peut descendre jusqu'au dixième niveau d'imbrication − rarement atteint en pratique − sans dépasser la moitié de la zone d'édition sur un terminal ou une vieille imprimante matricielle en 80 colonnes. En travaillant sous X-Window avec un écran plat moderne au format 16:9, j'ai un terminal de 208 colonnes. Je peux en ouvrir deux cotes à cotes et avoir encore de la place dans chacun d'eux.
En outre, cela structure le code dès le niveau syntaxique : quoi qu'il se passe, tout ce qui est dépendant d'une condition se trouve à l'intérieur d'un bloc. Ça permet entre autre d'utiliser facilement les fonctions de repliement de son éditeur de texte préféré. On pourrait même imaginer combiner cette fonction de repliement à l'état du debugger si on pouvait garantir que tous les programmes sources étaient rédigés de cette façon.
Ça permet également de poser tout de suite les post-conditions : par exemple, si la première étape d'un long cheminement consiste à ouvrir un fichier, eh bien je teste la validité du handler dans mon if(), j'ouvre le bloc et je place tout de suite le close() à la fin. Ensuite, j'insère la suite de mon code entre le début du bloc et ce close(). De fait, je suis sûr de ne jamais l'oublier, que la suite du programme réussisse ou échoue. Ça permet de maintenir un programme sur de nombreuses années, y compris par plusieurs personnes différentes, qui n'ont pas besoin de savoir a priori que cela a été écrit auparavant. Dans le cas contraire, il faut mettre en place une procédure de sortie anticipée et penser à la remplir au fur et à mesure que le code évolue.
[^] # Re: GOTO : Nostalgie...
Posté par Jerome Herman . Évalué à 1.
http://kerneltrap.org/node/553/2131
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . Évalué à 2.
[^] # Re: GOTO : Nostalgie...
Posté par Prae . Évalué à 7.
Ca laisse supposer que tout le monde utilise un éditeur qui fait des display par bloc;
Perso dans mon vi, j'ai pas mis l'option et quand je vois des if de plusieurs kilomètres et qu'à la fin, je sais même plus où se trouve le ''if-end'', ca me perturbe beaucoup plus qu'un
if(!good)
return(false);
Les if imbriqués sur plusieurs km me font parfois penser à du HTML/XML: à la fin, on ne sait même plus pour qui est le tag de terminaison (surtout si on a bien fait des div parfout)
# J'aime bien PHP
Posté par Dorian . Évalué à 10.
On le trouve partout et c'est facile à utiliser, tac un index.php et c'est parti.
Le code ressemble beaucoup au C++, ca m'arrange.
La doc est accessible facilement, en français et en anglais.
Beaucoup de tutoriels et d'exemple un peu partout.
La lisibilité du code dépend vraiment de celui qui l'écrit, et ca c'est pas seulement en PHP, et je n'ai jamais aimé l'indentation forcée en Python.
Pour Python, j'ai jamais vu des tutoriels simples sur comment l'utiliser pour faire un site, et comment l'interfacer avec le Python.
Je pense me faire moinsser, mais lisez bien "pertinent", "inutile", il n'y a pas "je ne suis pas d'accord".
Pourtant Python est pas mal fait, et j'aimerais utiliser Pygments.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: J'aime bien PHP
Posté par goofy . Évalué à 1.
Parce que python ou ruby c'est super mais si t'es un ptit webmaster va trouver un hébergement mutualisé pas chère ... bon il y en a mais pas autant que LAMP.
Laisses les faire ils doivent sûrement préférer ASP ou C#.
Sinon j'ai installer pentaho et openbravo (appli JAVA), ce sont de ces usines gaz comparés a un vtiger, joomla et consors ...
De toute façon on peut faire n'importe quoi avec n'importe quel langage ( à part ADA peut être)
Oh oui moinsser moi ;) !!
[^] # Re: J'aime bien PHP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10.
On le trouve partout et c'est facile à utiliser, tac un menu démarrer et c'est parti.
L'interface e code ressemble beaucoup à win98, ca m'arrange.
La doc est accessible facilement, en français et en anglais.
Beaucoup de tutoriels et d'exemple un peu partout.
L'utilisabilité du système dépend vraiment de celui qui est admin, et ca c'est pas seulement avec winxp, et je n'ai jamais aimé l'organisation forcée des macs.
Bon, tu auras remarqué une ressemblance pas fortuite.
Le fait que ce soit partout, documenté par jean-kevin, et géré par son petit-frère ne rend pas le truc bien.
Personnellement, je préfère les trucs obscures qui font exactement ce qu'on leur demande, qui le font bien, et tant pis si je dois faire une entorse à mon indentation habituelle ou à mon paradigme de programmation favori.
D'ailleurs, pour beaucoup de sites web dynamiques, il serait plus utile de filer un accès à la base de donnée, et de filer les specs des tables pour qu'on code un client au niveau OSI 7 qui récupère et traite les données proprement, sans passer par HTTP(S) qui n'est souvent pas fait pour ça.
Sur ces entrefaits, je vais coder une interface NNTP en APL pour lire les journaux sur ma chaîne hi-fi.
[^] # Re: J'aime bien PHP
Posté par gazbhan . Évalué à 1.
[^] # Re: J'aime bien PHP
Posté par maximegb . Évalué à -4.
1) PHP est un logiciel libre, donc tu peux le patcher pour qu'il corresponde mieux à tes besoins.
2) PHP n'est pas en position de monopole, donc tu peux utiliser autre chose sans (passer pour un extraterrestre|être coincé par un problème de driver).
[^] # Re: J'aime bien PHP
Posté par Jean B . Évalué à 4.
La licence te l'autorise, par contre le code source du moteur ... rien que coder une extension c'est une horreur.
Je te laisse comparer
http://www.php.net/manual/fr/internals2.structure.modstruct.(...)
à
http://docs.python.org/c-api/
[^] # Re: J'aime bien PHP
Posté par Prae . Évalué à 3.
Je conseille plutôt ces documentations: http://www.whenpenguinsattack.com/2006/11/15/how-to-write-ph(...) ou http://devzone.zend.com/article/1021
[^] # Re: J'aime bien PHP
Posté par Prae . Évalué à 1.
WTF ?!!
T'as craqué là.
[^] # Re: J'aime bien PHP
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Je penses pas que le monde est prêt à avoir une application à installer à chaque fois qu'il veut voir une site.
Je suis d'accord avec le fait qu'on est un peu en train de faire passer n'importe quel protocole encapsulé dans du HTTP, mais de là à avoir un client par site web ... (où alors il y a google).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: J'aime bien PHP
Posté par gazbhan . Évalué à 2.
[^] # Re: J'aime bien PHP
Posté par Dorian . Évalué à 3.
Désolé de te le dire à toi personnelement car tu n'es pas le seul, mais tu te crois supérieur !
Le mec qui a trouvé une astuce pour afficher un tableau proprement, il est content de lui, et alors, pas la peine de l'appeler un kevin.
Le fait que PHP soit bien documenté et que plein de gens en parlent dans leurs blogs et dans les forums, c'est pas un hasard.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: J'aime bien PHP
Posté par totof2000 . Évalué à 2.
s/php/windows/ comme d'autres l'ont déjà fait.
s/php/MSOffice/
s/php/n_importe_quel_produit_pourri_mais_populaire/
[^] # Re: J'aime bien PHP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 8.
Je ne crois vraiment pas que PHP soit convenablement documenté −d'une manière officielle, par les gens qui l'ont conçu− et je crois aussi (bien que je ne passe pas mon temps dessus) que les blogs qui parlent de PHP ne volent pas haut, mais j'ai tendence directement à ne pas les lire.
Le gars qui trouve une astuce pour afficher un tableau proprement, j'appelle ça un jean-kevin, ou un lycéen. C'est un truc par un gars qui sait pas coder pour aider les autres qui ne savent pas coder, mais qui seront heureux de faire pareil. Tant mieux s'il est content de lui. Mais il aurait jamais du en arriver là tant c'est bâteau.
PHP est *le* langage qui permet à des gens sans compétence de gagner leur vie. Quand tu sais pas coder, tu fais pas du perl, du python ou je ne sais quoi. En revanche, t'as fait ton site en PHP, et ptet même celui de ton oncle accordéoniste.
Je ne nie pas que des pros fassent effectivement du PHP, et qu'ils en fassent bien, je nie juste le fait que la majorité des gens qui font du PHP soient compétents. On ne compte pas le nombre de métiers du web où le code à été fait par ceux dont ce n'est pas le métier, ni la formation (graphistes, illustrateurs, etc). Et dire que le graphiste peut être un passionné doué n'y changera rien : t'as assez de gens qui font des études d'info sans y arriver pour qu'on se dise qu'il y a des gens qui n'ont aucune connaissance qui n'y arrivent pas mieux. Et ces gens font du PHP car justement, c'est répandu…
Quant à moi, je ne fais pas de web, ça résout le problème de la partialité pour RoR, python ou autre.
[^] # Re: J'aime bien PHP
Posté par Jean B . Évalué à 2.
http://prendreuncafe.com/blog/post/2006/11/22/12-astuces-opt(...)
[^] # Re: J'aime bien PHP
Posté par vieuxshell (site web personnel) . Évalué à 2.
http://code.google.com/speed/articles/optimizing-php.html
Et la réponse qui va bien de la part des dev php:
http://groups.google.com/group/make-the-web-faster/browse_th(...)
Grosso-modo pour éviter de cliquer sur les liens, google conseille d'utiliser des techniques d'optim qui datent de PHP4 et rendent le code au mieux illisible au pire font perdre des heures pour rien. Les devs PHP répondent qu'avant de filer des conseils pourris, google ferait bien de vérifier ses dires avec une implémentation récente du langage.
# Critiques de PHP
Posté par ǝɹɹǝıd oɯɐɹʇ . Évalué à 10.
Moi perso, j'aime bien PHP aussi et je ne pense pas que les gens qui l'utilisent soient tous masochistes ou incompétents.
PHP est ce qui fait que le libre à une grosse visibilité sur Internet.
Alors oui PHP est très permissif comme langage, mais rien ne vous empêche d'être propre dans votre code.
Après c'est une question de point de vue, les développeurs python on horreur de PHP, c'est leur choix.
Il faut aussi à des moments se poser les vrais questions.
Pourquoi PHP, aussi imparfait soit-il est si utilisé, alors que je n'ai toujours pas vu de pub à la télé pour PHP?
Ben il est efficace sur plusieurs point:
- facile d'apprentissage, sa trop grande permissivité aux erreurs n'est pas forcément un handicape pour les programmeurs débutants;
- facile de déploiement, la majorité des applications qui utilisent ne nécessitent pas de reconfiguration du serveur;
- adapter à internet;
- très bien intégré à Apache;
- facile de maintenance, on redémarre pas un site parce qu'on a changé un fichier;
Je pense qu'il faut de temps en temps arrêter la branlette cérébrale.
Si vous voulez faire du code PHP propre vous pouvez.
Vous pouvez poussez le vice jusqu'à typer les paramètres de vos méthodes, demander l'affichage des notices pour être sure que toutes vos variables ont bien étés initialisées.
Donc PHP, n'est pas et ne sera jamais le langage ultime.
Pour certain, il a été conçu pour être un mauvais langage mais personne n'est obligé de l'utiliser.
Maintenant, les types qui expliquent que si python ou java sont peu utilisés c'est parce que leur super langage a peu d'hébergeurs.
Je leur donne une astuce pour devenir riche :
OVH loue des serveurs dédiés http://www.kimsufi.com/ , à partir de 20 euros HT par mois.
Ils n'ont qu'a en louer 1, ce mettre en auto-entrepreneur pour faire de l'hébergement mutualisé dessus et devenir riche au lieu de pleurnicher.
Je sais pas, mais si je pensais que les gens n'utilisent pas un truc qu'ils veulent pourtant utiliser, un langage parfait, le rêve des développeurs, juste pour une raison si bête, c'est ce que je ferai et en plus ça me rendrait sûrement riche.
# langage pour et langage de
Posté par Camille_B . Évalué à 10.
La vérité est que si PHP n'est généralement pas aimé des devs c'est qu'il n'est pas bandant. Perl est amusant ; les LISP sont géniaux et excitants ; Python inspire le respect ; Ruby étonne... PHP, lui, ne fait rien, c'est un bidule sans âme.
PHP partage avec Perl une origine qui ne préfigurait rien de son avenir et une histoire faite d'ajouts successifs aussi inattendus qu'inégaux. Mais il y a une différence de taille. Perl fut pensé par un bordélique pour être bordélique, d'un bordel bien fun. PHP devin bordélique par accident, ou plutôt par inconscience.
Et ça se sent ! Le bordel de Perl c'est le bordel mi-chic mi-kitsch qui fait de l'oeil aux dandys. Le bordel de PHP c'est juste le bordel d'une chambre d'informaticien boutonneux qui a oublié d'apprendre à passer l'aspirateur et le plumeau.
Python méprise PHP, il est bien trop sale pour Monsieur Propre ; Perl se rit de PHP, un langage plus jeune que lui qui a fait les même conneries que lui sans prendre son génie ; LISP ne sait pas que PHP existe, il a bien trop à faire avec ses frères, ses cousins, ses petits-fils, ainsi qu'avec tous ces opportunistes qui viennent lui piquer telle et telle idée après s'être moqués de ses jolies parenthèses ; C radote dans son coin et continue de répéter pendant trois heures ce que LISP a déjà dit il y a 10 ans en deux minutes, autant que PHP lui passe à côté de ses pompes ; Ruby rigole avec PHP, il rigole avec tout le monde, Ruby est so coooool ; Java a trop de papiers à remplir ; et .NET se dit que s'il pouvait foutre PHP dans son bazar ça ameuterait une sacré bande de gaillards, ah ? c'est déjà fait ? Ne parlons pas d'Objective-C qui a d'autres tigres à fouetter.
Miaou !
# Dépréciations
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Tout ce qui est safe_mode et magic_quotes sont dépréciés. mysql_escape_string, ereg* et split aussi. Et un truc déjà déprécié depuis longtemps jette des erreurs maintenant : $string{5}, à remplacer par $string[5] (renvoie le 6ème caractère de $string, oui on compte à partir de zéro).
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Dépréciations
Posté par Patrick Lamaizière (site web personnel) . Évalué à 1.
J'ai cru comprendre que safe_mode est juste une blague n'importe comment :
http://www.vuxml.org/freebsd/ee6fa2bd-406a-11dd-936a-0015af8(...)
Le commentaire est rassurant :-(
Perso j'utilise php pour faire tourner SquirrelMail et ce n'est pas un logiciel en qui j'ai confiance.
les pixels au peuple !
[^] # Re: Dépréciations
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
http://www.vuxml.org/freebsd/ee6fa2bd-406a-11dd-936a-0015af8(...)
les pixels au peuple !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.