en gros :
→ je pond mon appli en C : je tente de compiler, j'ai des erreurs, des warnings... en cas d'erreur, ça compile pas, en cas de warning, ça compile.
→ je pond mon appli en php : je lance le script, j'ai des erreurs, des warnings... en cas d'erreur, ça se lancera pas, en cas de warning ça se lance...
\o/
Oui, on se doute bien qu'un code syntaxiquement/semantiquement invalide ne va pas s'executer...
Tout comme du code machine inexecutable ne s'executera pas, t'auras ton erreur, et paf.
Ca nous avance pas tellement ton histoire la.
Maintenant, la difference, c'est que ton erreur/warning, en interprete, tu n'as aucun moyen de la detecter avant d'executer le bout de code en question.
Et des tests de couverture de code ecrit manuellement, c'est lourd et difficile a ecrire.
mais dans la mesure où la gestion de la mémoire est gérée par l'interpréteur, de même que les accès disque et système, et que, dans le cas de php, on a pas de typage strict ni de déclaration des variables : ça n'est pas "grave"
Tu sais, avec une VM, ta gestion de la memoire, les acces disque et tout le tralala, c'est gere par la VM, on est dans le meme cas.
D'ailleurs je vois pas en quoi c'est pas grave, ton code est errone, c'est ca qui est grave, fondamentalement.
La facon de rattraper les erreurs, meme si elle peut etre appreciable, reste accessoire.
ça aussi, c'est logique, mais on va pas faire la même appli en c et en php... il y a une notion de contraintes qu'il faut prendre en compte
Non, c'est sur.
Apres, en Java et en php, tu peux faire la meme appli. Et yen a une qui donnera moins de cheveux blancs aux devs (ou moins de boulot, c'est selon, mais comme l'a dit timaniac, on a pas toujours le choix des delais de developpement/test) a la mise en prod.
Des tests unitaires, ca prend deja pas mal de temps (en l'occurence, a peu pres autant de code de test que de code normal).
Si en plus tu dois te rajouter des tests a la con du genre "verifier le type de retour de la fonction", tu t'en sort plus.
[^] # Re: d'un autre coté ...
Posté par thedude . En réponse au journal N'installez pas PHP 5.2.7 !. Évalué à 2.
→ je pond mon appli en C : je tente de compiler, j'ai des erreurs, des warnings... en cas d'erreur, ça compile pas, en cas de warning, ça compile.
→ je pond mon appli en php : je lance le script, j'ai des erreurs, des warnings... en cas d'erreur, ça se lancera pas, en cas de warning ça se lance...
\o/
Oui, on se doute bien qu'un code syntaxiquement/semantiquement invalide ne va pas s'executer...
Tout comme du code machine inexecutable ne s'executera pas, t'auras ton erreur, et paf.
Ca nous avance pas tellement ton histoire la.
Maintenant, la difference, c'est que ton erreur/warning, en interprete, tu n'as aucun moyen de la detecter avant d'executer le bout de code en question.
Et des tests de couverture de code ecrit manuellement, c'est lourd et difficile a ecrire.
mais dans la mesure où la gestion de la mémoire est gérée par l'interpréteur, de même que les accès disque et système, et que, dans le cas de php, on a pas de typage strict ni de déclaration des variables : ça n'est pas "grave"
Tu sais, avec une VM, ta gestion de la memoire, les acces disque et tout le tralala, c'est gere par la VM, on est dans le meme cas.
D'ailleurs je vois pas en quoi c'est pas grave, ton code est errone, c'est ca qui est grave, fondamentalement.
La facon de rattraper les erreurs, meme si elle peut etre appreciable, reste accessoire.
ça aussi, c'est logique, mais on va pas faire la même appli en c et en php... il y a une notion de contraintes qu'il faut prendre en compte
Non, c'est sur.
Apres, en Java et en php, tu peux faire la meme appli. Et yen a une qui donnera moins de cheveux blancs aux devs (ou moins de boulot, c'est selon, mais comme l'a dit timaniac, on a pas toujours le choix des delais de developpement/test) a la mise en prod.
Des tests unitaires, ca prend deja pas mal de temps (en l'occurence, a peu pres autant de code de test que de code normal).
Si en plus tu dois te rajouter des tests a la con du genre "verifier le type de retour de la fonction", tu t'en sort plus.