/* Topic des codeurs couche-tard [5] */

Кຼزດ · Le 15/06/2011, à 10:03

Pylades · Le 15/06/2011, à 12:30

grim7reaper a écrit :

Hé béh, successful troll is successful ^^"

Hé oui. Tout le mérite en revient au Rouge. Avec deux-trois mecs qui ne supportent pas PHP qui arrivent avec leur gros sabots et ArkSeth, cela ne pouvait que fonctionner. Je vois d’ailleurs pas ce trouve ArkSeth à ce langage, qui est du début à la fin blindé d’ignominies (en plus d’avoir une syntaxe moche ; franchement, on se demande à quoi servent les $). Les messages d’erreur en hébreux et les opérateur ternaire associatifs de gauche à droite, rien qui ça, ça devrait suffire à dégoûter du truc, non ? Fin bon, il n’y a peut-être que moi qui refuse d’utiliser des langages quand ils ne me conviennent pas (comme Python 2)… D’ailleurs, PHP peut-il convenir à des gens ? À des gens qui ne s’intéressent qu’à la facilité de déploiement, sans doute, mais en tant que langage de programmation ? Ça dépasse mon entendement (pourtant, les langages de programmations qui ne sont pas boiteux de tous les côtés, ça existe)…

grim7reaper a écrit :

Pylade a écrit :
que les gens qui veulent faire du code propre ne devraient pas utiliser PHP…
Encore une fois, source !?
C'est pas dans mon lien en tout cas.
Y'a suffisemment de citation à l'encontre de PHP pour que tu n'ais pas à en inventer en plus…

Ben, la phrase du genre de celle qu’a lancée Tman. Mais ça n’est pas trouvé par les moteurs de recherche, donc ça ne devait pas être exactement ça…

Dr Le Rouge · Le 15/06/2011, à 12:38

Pylade a écrit :

grim7reaper a écrit :
Hé béh, successful troll is successful ^^"
Hé oui. Tout le mérite en revient au Rouge.

Bon, j'ai réussi, j'me barre :

(ou pas ^^)

Dernière modification par Dr Le Rouge (Le 15/06/2011, à 12:38)

The Uploader · Le 15/06/2011, à 12:47

(pourtant, les langages de programmations qui ne sont pas boiteux de tous les côtés, ça existe)…

Pour le Web, ouaip : Il y a Ruby (on Rails)...

Pour les fous, il y a PHP...

Pylades · Le 15/06/2011, à 12:48

Par exemple !

Elzen · Le 15/06/2011, à 12:59

Pylade a écrit :

L’exception est une solution, NaN en est une autre. Dans les deux cas, l’erreur est signalée ; ce n’est pas silencieux (les exceptions permettant en plus de voir tout de suite d’où ça vient).

Renvoyer false en serait une troisième. Eux on choisis de faire un truc un peu moins pratique, bon, ç'pas génial, mais honnêtement, es-tu d'accord avec tous les points pour n'importe quel autre langage ?
J'ai pas d'exemple en têtes, mais il y a tout un tas d'autres langages où, pour un truc précis donné, il y a des erreurs silencieuses.

J'dis depuis le début que PHP n'est pas exempt de problèmes. La seule raison pour laquelle je le défend, c'est que vous le critiquez soit pour des trucs purement subjectifs, soit pour des trucs que vous pourriez reprocher à d'autres langages, mais qui, curieusement, ne vous dérangent que quand il s'agit de troller sur PHP.

Pylade a écrit :

Je ne vois pas de quoi tu parles (pour les histoires de type). Qu’as-tu contre les exceptions ?

Bah, si j'ai bien compris ce dont tu ne parles pas, je parle d'un opérateur qui renvoie vrai si on lui passe deux trucs exactement convertibles l'un en l'autre, mais qui ne sont pas du même type (genre en C, qui te dirait que 42 et '*' sont la même chose), et d'un second qui teste aussi le type (qui te dirait le contraire, puisque même si un char est un int, les deux sont déclarés comme de deux types différents).
Moyennant un peu de surcharge, ça pourrait également être utilisé dans un contexte objet : l'un pourrait, si le programmeur l'a décidé, renvoyer vrai si on a deux objets issus de deux implémentations différentes de la même interface, mais présentant les mêmes propriétés, tandis que l'autre renverraient faux, parce que du coup ce n'est pas le même objet.
Un opérateur d'équivalence distinct de l'opérateur d'égalité, quoi. (Bon, à titre personnel, j'aurais peut-être plus choisi de garder == pour le second et d'introduire autre chose pour le premier… à voir).

Sinon, ce que j'ai contre les exceptions ?
Rien, si ce n'est que ce n'est pas toujours adapté. Ç'bien toi qui a une citation de défense des goto dans ta signature ? Bah le principe est le même : y a des moments où c'est adapté, et y en a d'autres ou ça l'est pas.
Quand on fait de la programmation événementielle, déclencher des exceptions, ouais, ç'logique. Sinon, moins.

Pylade a écrit :

Ah, ouais, tu veux un symbole par opérateur ? Et quand il y a beaucoup d’opérateurs ? Tu leur donne des symboles à rallonge (deux signes c’est déjà trop ). À moment donné, il faut qu’un langage interprète le symbole en fonction du contexte, sinon c’est terrible. Tu n’as jamais essayé Perl, je parie… ^^
Au passage, c’est aussi tout un pan des langages orientés objet que tu remets en question : la surcharge des opérateurs, toussa…

Pas un symbole par opérateur, un symbole par classes d'opérateurs. Multiplier et déréférencer n'ont juste rien à voir, pas plus qu'additionner et concaténer.
Pour la surcharge des opérateurs, t'es bien d'accord pour dire qu'on ne surcharge pas n'importe quoi n'importe comment ? Genre si tu redéfinis - entre deux objets, c'est que tu veux définir une opération de soustraction entre eux, il ne te viendrait pas à l'idée de redéfinir - pour effectuer une exponentielle ?

Non, je ne me suis effectivement jamais penché vraiment sur le Perl, mais il me semble que c'est précisément de lui que vient la distinction faite par PHP entre « + » et « . ».

Pylade a écrit :

Ça, c’est un comportement civilisé. Passer un truc comme ça sous silence, c’est criminel et ça ne se justifie jamais.

Un comportement certes « civilisé » (ou pas, selon si le contexte se prête aux exceptions ou non), mais qui ne correspond pas aux conditions fournies.
Ç'tellement facile, de critiquer un comportement, en proposant à la place un truc qui n'est juste absolument pas adapté…

Ne pas prévenir de l'erreur, j'suis d'accord, ç'pas glop. Ça devrait plutôt renvoyer faux ou NaN. Mais balancer une exception, vu le contexte, est juste une encore plus mauvaise solution.

Pylade a écrit :

Le seul autre langage que je connaisse où le entiers sont des chaînes, c’est le shell. Et encore, pas tout à fait, on demande explicitement de comparer des chaînes en temps qu’entier. Là, c’est un comportement sain. Sinon, WTF, c’est impossible de coder correctement.

Bah justement, moi j'vois PHP comme un genre de Shell (l'effet « $ », sûrement ^^).
Et en PHP, comme en Shell, on demande explicitement comment on veut comparer les trucs, c'est la distinction entre == et === que j'explique ci-dessus.

Pylade a écrit :

C’est défini dans le langage ; c’est de l’arithmétique des pointeurs. Ça a un sens. Et en plus, c’est vraiment efficace. Essaie de faire la multiplication entre un entier et un pointeur, là le compilo va râler.

Comme tu dis : c'est défini dans le langage.
En PHP, c'est défini dans le langage qu'on puisse additionner des chaînes avec des entiers. Ça a un sens aussi, celui fourni par la spec (l'arithmétique des pointeurs en C n'a de sens que parce que la spec lui en donne ; oublie la spec et ça n'en a plus). Et en plus, c'est vraiment efficace.

T'es juste en train d'essayer de défendre le C et d'enfoncer le PHP exactement pour le même concept. J'ai assez d'estime pour ton intelligence pour supposer que c'est juste de la mauvaise foi…

Après, j'vous accorde que le langage n'est pas forcément super bien pensé sur tous les points, et que son interpréteur ajoute d'autres problèmes, ça, bien d'accord. Seulement, on peut dire la même chose de pas mal d'autres langages (en remplaçant juste « interpréteur » par « compilateur » selon le cas).
PHP n'est pas la panacée, mais n'a rien de foncièrement pire que les autres.

Toi particulièrement, Pylade, connaissant ce que tu penses de Python 2 et de Python 3, tu devrais être le premier à reconnaître que si on se décidait à refaire un PHP en changeant l'interpréteur et en brisant la rétrocompatibilité juste sur une poignée de points, ça pourrait donner un truc très bien, même si la version actuelle ne te convient pas.

Dr Le Rouge · Le 15/06/2011, à 13:02

epic win !

'o' \m/

Moi j'aime pas php pour des raisons affreusement subjectives, et j'assume

edit : ordre des mots douteux

Dernière modification par Dr Le Rouge (Le 15/06/2011, à 13:09)

The Uploader · Le 15/06/2011, à 13:30

STOP! On est à 256 réponses! C'trop beau!
....
....
....

Ah, merde..

Dernière modification par The Uploader (Le 15/06/2011, à 13:32)

Elzen · Le 15/06/2011, à 13:40

Pylade a écrit :

Je vois d’ailleurs pas ce trouve ArkSeth à ce langage

Je n'ai aucune affection particulière pour quelque langage que ce soit, soit dit en passant.

J'ai juste deux principe de base :
– Si rien n'est parfait, rien non plus n'est une infâme bouse sans nom bourrée de défauts et totalement dénuée de qualités ; et toute qualité mérite d'être défendue.
– Si quelqu'un s'acharne à dézinguer quelque chose à coups d'arguments incohérents ou purement subjectifs, cette personne se trompe, et quelqu'un doit lui répondre.

Et comme j'attends d'une communauté constituée de gens doués de raisons et ouverts d'esprits –c'est ainsi que j'estime pouvoir considérer le TdCCT– qu'ils soient capables de faire la différence entre un avis purement subjectif et un véritable argument, j'ai tendance à m'accrocher d'autant plus à ces principes.

tshirtman · Le 15/06/2011, à 14:00

ArkSeth a écrit :

J'dis depuis le début que PHP n'est pas exempt de problèmes. La seule raison pour laquelle je le défend, c'est que vous le critiquez soit pour des trucs purement subjectifs, soit pour des trucs que vous pourriez reprocher à d'autres langages, mais qui, curieusement, ne vous dérangent que quand il s'agit de troller sur PHP.

Ben disont qu'il cumule quoi… et vu son status de "roi du web" et les armées de gens sans considérations qui en font, cette somme d'erreurs produit des catastrophes et autres bombes a retardements en pagailles…

Sinon, ce que j'ai contre les exceptions ?
Rien, si ce n'est que ce n'est pas toujours adapté. Ç'bien toi qui a une citation de défense des goto dans ta signature ? Bah le principe est le même : y a des moments où c'est adapté, et y en a d'autres ou ça l'est pas.

Pour l'anecdote, LE cas d'utilisation justifiable du goto en C existe précisément par ce que les exceptions n'y sont pas présente, c'est typiquement l'endroit ou on les voudrait pour gérer le truc, mais bon y'a pas, alors du gout, ils bricolent une sortie de flux (exactement le principe des exceptions) à un seul niveaux, par ce que le faire à plus serait suicidaire avec des goto… c'est un pis-aller

Quand on fait de la programmation événementielle, déclencher des exceptions, ouais, ç'logique. Sinon, moins.

Loin s'en faut, ça n'a aucun rapport avec l’événementiel, tu peux tout à fait utiliser les exception pour gérer certains cas dans des traitements par lots de logs ou de commandes ou je ne sais quoi, une opération peut échouer de différentes façons et tu veux pouvoir effectuer un traitement spécial dans chaque cas? → exception… stou! (hors les bricolages avec des tests de masques sur des valeurs de retours, technique préhistorique au possible, et limité à un niveau de traitement)

Multiplier et déréférencer n'ont juste rien à voir, pas plus qu'additionner et concaténer.

Je m'insurge, concaténer est une forme d'addition tout à fait recevable, pas commutative, certes, mais associative, à n opérandes, etc… alors que déréférencer n'a rien d'arithmétique…

Ne pas prévenir de l'erreur, j'suis d'accord, ç'pas glop. Ça devrait plutôt renvoyer faux ou NaN. Mais balancer une exception, vu le contexte, est juste une encore plus mauvaise solution.

pourquoi? tu n'aime pas pouvoir gérer tes cas de bords ou avoir un backtrace de ta pile d'execution quand on tombe sur ce cas non encore géré? Enfin, je ne vois aucun défaut à l'apport des exception, mais je t'en pris, si tu en as, développe…

Bah justement, moi j'vois PHP comme un genre de Shell (l'effet « $ », sûrement ^^).

On est d'accord, ne rien faire de plus de 50 lignes en shell, idem en php…

PHP n'est pas la panacée, mais n'a rien de foncièrement pire que les autres.

Il y a beaucoup moins de langages populaires que de langages, on attends un peu de qualité des langages populaires, histoir de pas être trop casse gueule… php ne réponds pas à ce critère, stou… après, je pense du mal du java, du C++, du php, du C#, du lisp, du erlang, du haskell… et même peut être de python (mais bon, pas beaucoup ) donc pour moi y'a pas beaucoup de bons langages, mais les erreurs du php sont particulièrement frustrantes par ce qu'elles sont bêtes, qu'elles se rendent plus insuportables en se combinants, et qu'on subbit php partout…

Dernière modification par tshirtman (Le 15/06/2011, à 14:04)

Elzen · Le 15/06/2011, à 14:32

tshirtman a écrit :

Ben disont qu'il cumule quoi… et vu son status de "roi du web" et les armées de gens sans considérations qui en font, cette somme d'erreurs produit des catastrophes et autres bombes a retardements en pagailles…

Ça, même si PHP était à la limite de la perfection, le fait qu'il soit le seul langage Web utilisable (D'ailleurs, tant qu'on en parle, j'pense que pour ASP, c'est mort, mais quelqu'un voudrait se charger de la défense de JSP ? Il en faudrait au moins un, quoi ) est un énorme problème en soit.
La diversité, sayLEbien.

tshirtman a écrit :

Loin s'en faut, ça n'a aucun rapport avec l’événementiel, tu peux tout à fait utiliser les exception pour gérer certains cas dans des traitements par lots de logs ou de commandes ou je ne sais quoi, une opération peut échouer de différentes façons et tu veux pouvoir effectuer un traitement spécial dans chaque cas? → exception… stou! (hors les bricolages avec des tests de masques sur des valeurs de retours, technique préhistorique au possible, et limité à un niveau de traitement)

Effectivement, tu peux utiliser du traitement par exception dans d'autres cas que de l'événementiel, comme tu peux pour plein de raisons préférer éviter les exceptions en événementiel. J'ai juste mis le premier truc qui me passait par la tête pour ne pas passer trois plombes à chercher⁽¹⁾ les cas où c'est bien et ceux où ça l'est moins, mea culpa.

Sinon, à titre personnel, j'ai tendance à trouver un switch/case sur la valeur de retour largement plus lisible qu'une suite de try/catch (ou try/except, mais en Python y a pas de switch/case), mais je reconnais que c'est purement subjectif.
Et puis il y a peut-être aussi une réaction au fait que j'ai subi récemment, en Java, des cas où tu es obligé de foutre un try/catch alors que tu sais pertinemment que l'exception ne sera jamais déclenchée.

(1) Comme pour pas mal de règles de grammaires, genre le bon usage du « ; », j'ai juste énormément de mal à t'expliquer les critères qui font que ça me paraît justifié ou pas, je les ai tellement intériorisés que ça me vient spontanément… et parfois, j'me goure.

tshirtman a écrit :

Je m'insurge, concaténer est une forme d'addition tout à fait recevable, pas commutative, certes, mais associative, à n opérandes, etc… alors que déréférencer n'a rien d'arithmétique…

Donc le C est encore moins logique que le PHP, bien vu

(Plus sérieusement, niveau algorithmique du texte sur papier, la concaténation est plus souvent assimilée à une multiplication qu'à une addition, me semble-t-il, ce qui me semble un poil plus logique.)

tshirtman a écrit :

pourquoi? tu n'aime pas pouvoir gérer tes cas de bords ou avoir un backtrace de ta pile d'execution quand on tombe sur ce cas non encore géré? Enfin, je ne vois aucun défaut à l'apport des exception, mais je t'en pris, si tu en as, développe…

Bah j'aurais du mal à expliquer ça comme ça, mais c'est le principe des exceptions (ça remonte jusqu'à ce que ce soit attrapé, ou que ça fasse crasher le truc entier) qui me paraît inadapté au mode de fonctionnement client/serveur avec réponse progressive des pages Web.
Pour moi, dans ce cas particulier-ci, il est largement plus propre de laisser l'exécution jusqu'au bout, plutôt que de devoir s'interrompre en cours de route, et de devoir éventuellement faire avec le bout de document XML qui aurait déjà été renvoyé.

En même temps, je trouve aussi beaucoup plus propre de faire tout le traitement d'abord et de ne renvoyer la page complète que d'un coup à la fin, donc finalement les exceptions ne me dérangent pas tant que ça, mais ça me paraît quand même introduire plus de risques que ça n'apporte de solutions, tu vois ce que je veux dire ?

Dr Le Rouge · Le 15/06/2011, à 14:40

ArkSeth a écrit :

Et puis il y a peut-être aussi une réaction au fait que j'ai subi récemment, en Java, des cas où tu es obligé de foutre un try/catch alors que tu sais pertinemment que l'exception ne sera jamais déclenchée.

C'est vrai que la façon que ce langage d'imposer des blocs try/catch pour un oui ou pour un non est très chiante. Ça fait partie des choses qui me gavent, personnellement, au même titre que System.out.println() ^^

Elzen · Le 15/06/2011, à 14:49

System.out.println(), c'est un poil long à taper, mais quand même bigrement logique et sacrément explicite : tu t'adresses au machin qui connaît le système, pour lui demander la sortie standard (mais tu pourrais aussi demander la sortie d'erreur standard, System.err), à laquelle tu demandes d'afficher ta ligne.
Niveau fonctionnement, c'est juste le principe « orienté objet » superbement appliqué (tandis que les print ou echo des autres langages sont juste des aberrations quand tu essayes de penser un truc en full-OO).

Sinon, je suppose que forcer à récupérer l'exception peut être intéressant dans certains cas (genre pour un traitement sur un flux, où il vaut mieux ne pas oublier de le fermer à la fin, même si un truc à planté). Mais c'est juste pas utile dans la plupart des cas, où l'exception devrait hériter de RuntimeException (qui, comme ses classes-filles, n'a pas besoin d'être obligatoirement déclarée ni try/catchée) plutôt que de Exception.

Pylades · Le 15/06/2011, à 16:02

Tiens, j’ai propré mon .vimrc…

" Modelines are evil :P
set nomodeline

" Plugin and indentation rules according to the file type
if has("autocmd")
  filetype plugin indent on
endif

" Syntax highlighting
if has("syntax")
  syntax on
  set background=dark
endif

set showcmd
set number
set ruler

if has("mouse")
  set mouse=a
endif

" The .vimrc is automatically sourced when written
if has("autocmd")
  aug smart_rc
    au!
    au BufWritePost $MYVIMRC so $MYVIMRC
  aug end
endif

let c_syntax_for_h = 1
let c_space_errors = 1
let python_highlight_all = 1

hi Operator ctermfg=red guifg=red

ArkSeth a écrit :

Pylade a écrit :
L’exception est une solution, NaN en est une autre. Dans les deux cas, l’erreur est signalée ; ce n’est pas silencieux (les exceptions permettant en plus de voir tout de suite d’où ça vient).
Renvoyer false en serait une troisième. Eux on choisis de faire un truc un peu moins pratique, bon, ç'pas génial, mais honnêtement, es-tu d'accord avec tous les points pour n'importe quel autre langage ?
J'ai pas d'exemple en têtes, mais il y a tout un tas d'autres langages où, pour un truc précis donné, il y a des erreurs silencieuses.

Hum, false c’est plutôt fait pour être utilisé dans un contexte logique, non ? Pour moi NaN est bien plus explicite et approprié, mais c’est du détail.
Ce qui compte, c’est qu’une erreur ne passe jamais silencieusement. Et en C par exemple, je ne connais pas de cas où les erreurs passent silencieusement. En Python non plus.

ArkSeth a écrit :

J'dis depuis le début que PHP n'est pas exempt de problèmes. La seule raison pour laquelle je le défend, c'est que vous le critiquez soit pour des trucs purement subjectifs, soit pour des trucs que vous pourriez reprocher à d'autres langages, mais qui, curieusement, ne vous dérangent que quand il s'agit de troller sur PHP.

Ben ce qui me dérange, c’est que PHP soit plein d’erreurs, et ne permette pas de faire un programme fiable (ou alors au prix d’un effort immense) alors qu’il est énormément utilisé, et aveuglément. Et il y a des trucs qui me dérangent dans le C, comme par exemple l’inconsistance de l’ordre des arguments des fonctions d’IO ou la présence de fonctions à bannir dans la bibliothèque standard. Ça, c’est mal et je le dis. Sauf qu’avec le C, ça s’arrête là, et si tu veux faire les choses bien, tu peux.

ArkSeth a écrit :

Pylade a écrit :
Je ne vois pas de quoi tu parles (pour les histoires de type). Qu’as-tu contre les exceptions ?
Bah, si j'ai bien compris ce dont tu ne parles pas, je parle d'un opérateur qui renvoie vrai si on lui passe deux trucs exactement convertibles l'un en l'autre, mais qui ne sont pas du même type (genre en C, qui te dirait que 42 et '*' sont la même chose), et d'un second qui teste aussi le type (qui te dirait le contraire, puisque même si un char est un int, les deux sont déclarés comme de deux types différents).

Ah, OK. Ben en C, 42 et '*' sont du même type, entier, c’est juste qu’ils n’ont pas la même longueur. Mais sinon, les données qu’ils contiennent sont du même type. Et au passage, si t’es en EBCDIC, '*' est égal à 0x5C, pas 42.
Après, si et seulement si deux types sont comparables, les opérateurs peuvent les comparer (comparer entiers et flottants, par exemple). Mais vérifier que deux variables ont le même type, ce n’est pas le rôle d’un opérateur de comparaison !

ArkSeth a écrit :

Moyennant un peu de surcharge, ça pourrait également être utilisé dans un contexte objet : l'un pourrait, si le programmeur l'a décidé, renvoyer vrai si on a deux objets issus de deux implémentations différentes de la même interface, mais présentant les mêmes propriétés, tandis que l'autre renverraient faux, parce que du coup ce n'est pas le même objet.
Un opérateur d'équivalence distinct de l'opérateur d'égalité, quoi. (Bon, à titre personnel, j'aurais peut-être plus choisi de garder == pour le second et d'introduire autre chose pour le premier… à voir).

T’utilises deux implémentations différentes de la même interface en même temps ?

ArkSeth a écrit :

Sinon, ce que j'ai contre les exceptions ?
Rien, si ce n'est que ce n'est pas toujours adapté. Ç'bien toi qui a une citation de défense des goto dans ta signature ? Bah le principe est le même : y a des moments où c'est adapté, et y en a d'autres ou ça l'est pas.
Quand on fait de la programmation événementielle, déclencher des exceptions, ouais, ç'logique. Sinon, moins.

Admettons. J’ai toujours trouvé ça bien pratique, mais bon… Mais alors il faut proposer un mécanisme sain pour remonter les erreurs, au moins.

ArkSeth a écrit :

Pylade a écrit :
Ah, ouais, tu veux un symbole par opérateur ? Et quand il y a beaucoup d’opérateurs ? Tu leur donne des symboles à rallonge (deux signes c’est déjà trop ). À moment donné, il faut qu’un langage interprète le symbole en fonction du contexte, sinon c’est terrible. Tu n’as jamais essayé Perl, je parie… ^^
Au passage, c’est aussi tout un pan des langages orientés objet que tu remets en question : la surcharge des opérateurs, toussa…
Pas un symbole par opérateur, un symbole par classes d'opérateurs. Multiplier et déréférencer n'ont juste rien à voir, pas plus qu'additionner et concaténer.
Pour la surcharge des opérateurs, t'es bien d'accord pour dire qu'on ne surcharge pas n'importe quoi n'importe comment ? Genre si tu redéfinis - entre deux objets, c'est que tu veux définir une opération de soustraction entre eux, il ne te viendrait pas à l'idée de redéfinir - pour effectuer une exponentielle ?

Après c’est conceptuel… Il y a des gens (nombreux) qui voient la concaténation comme un genre d’addition. Personnellement ça ne me choque pas vraiment. Pas plus que que d’utiliser le même symbole pour la division entière et la division réelle, ou pour la concaténation et le point décimal.

ArkSeth a écrit :

Non, je ne me suis effectivement jamais penché vraiment sur le Perl, mais il me semble que c'est précisément de lui que vient la distinction faite par PHP entre « + » et « . ».

C’est surtout pour dire que dans Perl, le sens des expressions dépend du contexte, alors si tu n’aimes pas qu’un simple symbole puisse vouloir dire différentes chose en fonction du nombre ou du type de ses opérandes, je te vois mal faire du Perl… ^^

ArkSeth a écrit :

Pylade a écrit :
Ça, c’est un comportement civilisé. Passer un truc comme ça sous silence, c’est criminel et ça ne se justifie jamais.
Un comportement certes « civilisé » (ou pas, selon si le contexte se prête aux exceptions ou non), mais qui ne correspond pas aux conditions fournies.
Ç'tellement facile, de critiquer un comportement, en proposant à la place un truc qui n'est juste absolument pas adapté…

Ah, ben je propose un truc qui sied aux langages interprétés, pour un langage compiler et à typage fort, je proposerais de se faire jeter par le compilo. Pour un typage faible… euh, renvoyer une constante d’erreur serait déjà pas mal. T’façons, le typage faible, c’est pas bon.
Bon après tu n’aimes pas les exceptions, même si c’est bien pratique, OK. Mais là c’est toi que je trouve bien subjectif.

ArkSeth a écrit :

Ne pas prévenir de l'erreur, j'suis d'accord, ç'pas glop. Ça devrait plutôt renvoyer faux ou NaN. Mais balancer une exception, vu le contexte, est juste une encore plus mauvaise solution.

C’est quoi pour toi un contexte approprié pour les exceptions ?

ArkSeth a écrit :

Pylade a écrit :
Le seul autre langage que je connaisse où le entiers sont des chaînes, c’est le shell. Et encore, pas tout à fait, on demande explicitement de comparer des chaînes en temps qu’entier. Là, c’est un comportement sain. Sinon, WTF, c’est impossible de coder correctement.
Bah justement, moi j'vois PHP comme un genre de Shell (l'effet « $ », sûrement ^^).
Et en PHP, comme en Shell, on demande explicitement comment on veut comparer les trucs, c'est la distinction entre == et === que j'explique ci-dessus.

Je ne suis pas convaincu par == et ===, comme j’ai expliqué ci-dessus. Et en shell, ce n’est pas anodin de traiter une chaîne comme un nombre, il faut appeler explicitement expr, test avec l’option appropriée ou faire une substitution arithmétique. Ça ne se fait pas juste en utilisant n’importe quel opérateur de comparaison.

ArkSeth a écrit :

Pylade a écrit :
C’est défini dans le langage ; c’est de l’arithmétique des pointeurs. Ça a un sens. Et en plus, c’est vraiment efficace. Essaie de faire la multiplication entre un entier et un pointeur, là le compilo va râler.
Comme tu dis : c'est défini dans le langage.
En PHP, c'est défini dans le langage qu'on puisse additionner des chaînes avec des entiers. Ça a un sens aussi, celui fourni par la spec (l'arithmétique des pointeurs en C n'a de sens que parce que la spec lui en donne ; oublie la spec et ça n'en a plus). Et en plus, c'est vraiment efficace.

Et pourquoi donc, on peut additionner des chaînes et des entiers ? Ça a quoi comme sens ?
En plus ça m’étonnerait que ça soit dans la spec, car si ont le faire, c’est uniquement à cause du même bug que le support accidentel de l’octal. Tiens, tu ne m’avais pas répondu pour ça :

Pylade a écrit :

Et je n’ai pas essayé, mais je jurerais qu’une chaîne du style "\t \n 3plop" donnera 3…

Du coup, je suis allé tester moi-même (merci l’accès SSH d’Alwaysdata). Ben j’avais raison. Donc on a bien la preuve que ce n’est pas un comportement voulu : c’est un bug.

ArkSeth a écrit :

T'es juste en train d'essayer de défendre le C et d'enfoncer le PHP exactement pour le même concept. J'ai assez d'estime pour ton intelligence pour supposer que c'est juste de la mauvaise foi…

Ah non, en C on a une opération avec un sens, qui sert à quelque chose et qui est encadrée par la norme, en PHP on a un bug.

ArkSeth a écrit :

Après, j'vous accorde que le langage n'est pas forcément super bien pensé sur tous les points, et que son interpréteur ajoute d'autres problèmes, ça, bien d'accord. Seulement, on peut dire la même chose de pas mal d'autres langages (en remplaçant juste « interpréteur » par « compilateur » selon le cas).

Je n’ai pas trop à me plaindre de GCC (quelques bugs, j’en ai trouvé trois, mais pas bien méchants). Et le langage PHP est solidement lié à son implémentation de référence. Ce n’est pas un mal en soi (je ne me plains pas de Python ou Ruby), mais alors l’implémentation de référence doit être particulièrement irréprochable…

ArkSeth a écrit :

PHP n'est pas la panacée, mais n'a rien de foncièrement pire que les autres.

Si, son nombre important de trucs mal pensés ou implémentés et son utilisation massive (c’est le Windows des langages Web).

ArkSeth a écrit :

Toi particulièrement, Pylade, connaissant ce que tu penses de Python 2 et de Python 3, tu devrais être le premier à reconnaître que si on se décidait à refaire un PHP en changeant l'interpréteur et en brisant la rétrocompatibilité juste sur une poignée de points, ça pourrait donner un truc très bien, même si la version actuelle ne te convient pas.

Ben déjà, Python 2 n’était pas aussi mauvais que PHP, ce n’est pas rien. Il y a avait juste quelque choix discutables qui ne me plaisaient pas (notamment cette horreur de fonction input). Et plus avec la version 3, on a eu plein de beaux changements, avec une réelle volonté d’aller de l’avant, c’était cool. Si PHP voulait corriger ses défaut, ça se saurait. Et il n’y aurait pas toujours des messages d’avertissement en hébreu.

ArkSeth a écrit :

Pylade a écrit :
Je vois d’ailleurs pas ce trouve ArkSeth à ce langage
Je n'ai aucune affection particulière pour quelque langage que ce soit, soit dit en passant.
J'ai juste deux principe de base :
– Si rien n'est parfait, rien non plus n'est une infâme bouse sans nom bourrée de défauts et totalement dénuée de qualités ; et toute qualité mérite d'être défendue.
– Si quelqu'un s'acharne à dézinguer quelque chose à coups d'arguments incohérents ou purement subjectifs, cette personne se trompe, et quelqu'un doit lui répondre.
Et comme j'attends d'une communauté constituée de gens doués de raisons et ouverts d'esprits –c'est ainsi que j'estime pouvoir considérer le TdCCT– qu'ils soient capables de faire la différence entre un avis purement subjectif et un véritable argument, j'ai tendance à m'accrocher d'autant plus à ces principes.

C’est un peu ça : http://xkcd.com/386/.

ArkSeth a écrit :

System.out.println(), c'est un poil long à taper, mais quand même bigrement logique et sacrément explicite : tu t'adresses au machin qui connaît le système, pour lui demander la sortie standard (mais tu pourrais aussi demander la sortie d'erreur standard, System.err), à laquelle tu demandes d'afficher ta ligne.
Niveau fonctionnement, c'est juste le principe « orienté objet » superbement appliqué (tandis que les print ou echo des autres langages sont juste des aberrations quand tu essayes de penser un truc en full-OO).

En Python, print n’est qu’un raccourci vers, par défaut, sys.stdout.write en proposant quelques opération en plus (mais tu peux choisir d’utiliser un autre flux). C’est une aberration pour un langage OO ?

Et je lirai la suite du troll plus tard…

The Uploader · Le 15/06/2011, à 16:19

En Java, tu peux raccourcir System.out.println en ayant fait import System.out.*

En fait dans ma phrase précédente, on peut remplacer Java par C#, dans ce cas là c'est pareil (sauf que import devient using).

Mais ça ne résout pas l'aspect bavard de Java, loin de là :

FileStream MyStream=new FileStream(new BufferedStream(new Stream()))

C'est de mémoire, mais c'est déjà assez redondant comme ligne de code..

En Python, print n’est qu’un raccourci vers, par défaut, sys.stdout.write en proposant quelques opération en plus (mais tu peux choisir d’utiliser un autre flux). C’est une aberration pour un langage OO ?

Pour ma part, je ne crois pas.
M'enfin Ruby est encore plus OO-sugar :

> irb                                                           ~
irb(main):001:0> 5.times{puts "hello"}
hello
hello
hello
hello
hello
=> 5

Magiqueuhhh!
Tiens d'ailleurs, j'ai vu ça Ruby/SDL mais bon, je suis pas très chaud pour l'installer.. (j'parie que ça va être problématique..).
Pourtant, ça me démange d'essayer..

Dernière modification par The Uploader (Le 15/06/2011, à 17:23)

tshirtman · Le 15/06/2011, à 16:27

moi je dit, un langage ou for ne s'appelle pas lang.loop.for (ou sont rangés while) c'est pas un langage objet

The Uploader · Le 15/06/2011, à 16:29

Arrête, on dirait Snake046 qui troll sur python..

Elzen · Le 15/06/2011, à 17:21

Pylade a écrit :

Hum, false c’est plutôt fait pour être utilisé dans un contexte logique, non ? Pour moi NaN est bien plus explicite et approprié, mais c’est du détail.

Question de cohérence : NaN ne convient pas aux fonctions autres que numériques. Or il m'apparaît plus judicieux d'avoir un comportement cohérent (renvoyer faux en cas d'erreur peut être utilisé dans tout un tas de cas), quitte à rajouter des cas possibles en plus pour les comportements spécifiques (genre une fonction de division renverrait false si on lui demande de diviser un truc non numérique, et NaN si on lui demande de diviser par zéro).
Après, c'est vrai que pour un langage comme PHP, on pourrait aussi inventer une autre constante particulière, qui correspondrait au retour d'erreur « standard ».

Pylade a écrit :

Ben ce qui me dérange, c’est que PHP soit plein d’erreurs, et ne permette pas de faire un programme fiable (ou alors au prix d’un effort immense)

PHP permet de faire un programme fiable, sans spécialement plus d'efforts qu'avec d'autres langages. En tout cas, moi, j'y arrive, donc ça ne doit pas être tellement sorcier

Pour ce qui est de « faire les choses bien », il faudrait préciser ce que tu appelles bien. À titre personnel, et indépendamment de la propreté du langage lui-même, je trouve que ce que je fais en PHP est beaucoup plus propre, élégant et utilisable que ce que je fais en Python.

Concernant le fait que PHP soit énormément utilisé, confer ma réponse à tshirtman. Et c'est probablement une circonstance aggravante, mais ce n'est pas pour autant un défaut du langage lui-même.

Pylade a écrit :

Mais vérifier que deux variables ont le même type, ce n’est pas le rôle d’un opérateur de comparaison !

Ce n'est pas le rôle de certains opérateurs de comparaisons, comme supérieur, inférieur ou équivalence, où effectivement, il suffit que les types soient comparables.
En revanche, on peut, dans certains cas, avoir besoin de tester, plus qu'une équivalence, une égalité réelle. Un truc qui est capable de te dire que « 1,0 » et « 1 » ne sont pas tout à fait la même chose, c'est bien une comparaison.

Pylade a écrit :

T’utilises deux implémentations différentes de la même interface en même temps ?

Ça arrive, de temps à autres. Genre pour faire des tests, quand tu as deux implémentations possibles et que tu veux savoir laquelle est la mieux.
Ou alors quand une classe hérite d'une autre, genre en GTK, ComboBox et ComboBoxText.

Idem, je ne dis pas que c'est le truc dont on se sert tous les jours, je dis que dans certains cas, ça peut être indispensable.

Pylade a écrit :

Bon après tu n’aimes pas les exceptions, même si c’est bien pratique, OK. Mais là c’est toi que je trouve bien subjectif.

En partie, et en partie aussi que j'éprouve juste des difficultés à expliquer ma position. Confer ma réponse à tshirtman.
Mais même si je reconnais volontiers être subjectif sur ma manière de dire où il en faut et où il n'en faut pas (c'est principalement une question de propreté et de lisibilité, donc une question subjective), j'estime être objectif quand je dis qu'il y a des cas pour lesquels c'est préférable de ne pas balancer d'exceptions.

Pylade a écrit :

Je ne suis pas convaincu par == et ===, comme j’ai expliqué ci-dessus. Et en shell, ce n’est pas anodin de traiter une chaîne comme un nombre, il faut appeler explicitement expr, test avec l’option appropriée ou faire une substitution arithmétique. Ça ne se fait pas juste en utilisant n’importe quel opérateur de comparaison.

Le comportement de la commande test en shell, à qui on passe des arguments qui seront nécessairement des chaînes de caractères, ressemble énormément aux comparaisons PHP. En tout cas, à part le retour d'erreur qui est un autre problème dont on traite séparément à côté, et l'existence du === qui n'aurait pas de sens en shell parce que justement les paramètres sont forcément des chaînes de caractères, moi j'vois pas la différence, mais si tu veux me l'expliquer, je t'écoute.

Pylade a écrit :

Et pourquoi donc, on peut additionner des chaînes et des entiers ? Ça a quoi comme sens ?

Ça a comme sens que PHP, comme le Shell, reçoit ses arguments (ce qui est passé en GET ou en POST en plus des argv habituels) nécessairement comme étant des chaînes de caractères.
Quand tu ouvres l'interpréteur python et que tu tapes, par exemple, « 2 », c'est une chaîne de caractère qui est envoyée, mais elle est automatiquement castée en entier. Et donc quand tu tapes « 2 + i », si la variables i a précédemment été définie comme entière, tu demandes bien, techniquement, d'additionner un entier à une chaîne de caractères.
Tu le demandes à l'interpréteur python, et il te fait les casts automatiques qui vont bien pour pouvoir effectuer l'opération. La seule différence avec PHP, c'est que PHP, qui se veut permissif, ne caste pas les arguments extérieurs dès leur réception (devoir différencier, dans le formulaire HTML, « 2 » et « "2" » comme on le fait dans l'interpréteur python, ce serait quand même sacrément lourd), et permet donc de les autocaster en interne.
Je ne dis pas que c'est le meilleur choix, mais c'est un choix qui se tient.

Pylade a écrit :

Tiens, tu ne m’avais pas répondu pour ça :

Comme je l'ai dit, mon objectif n'est pas de défendre PHP bec et ongles. J'vous laisse le descendre tant que vous voulez, tant que vous utilisez pour cela des arguments recevables. Et pour le coup, effectivement, ç't'assez moche. Que les caractères blancs soient zappés, ça se comprend, le « plop », moins.

Pylade a écrit :

Ah non, en C on a une opération avec un sens, qui sert à quelque chose et qui est encadrée par la norme, en PHP on a un bug.

En PHP aussi, on a une opération avec du sens. Pas dénuée de bugs, manifestement, mais je répète encore une fois qu'il faut (même si ce n'est pas forcément évident avec un interpréteur de référence comme ça) distinguer la critique du langage de celle de son implémentation.
Sur la réalisation, c'est mal foutu. Sur la logique, ce n'est pas pire que ce qu'il y a en C.

Pylade a écrit :

En Python, print n’est qu’un raccourci vers, par défaut, sys.stdout.write en proposant quelques opération en plus (mais tu peux choisir d’utiliser un autre flux). C’est une aberration pour un langage OO ?

Tu peux régler cet « alias » pour qu'il pointe sur autre chose ? Et qu'entends-tu par « en proposant quelques opérations en plus », exactement ?
J'suppose que si on voit ça comme un genre de variable autodéclarée pointant vers une méthode précise d'un objet précis, et pas comme une commande à part, ça peut être recevable…

Concernant le troll de tshirtman que je vois juste à temps en prévisualisant (prévisualiser, saybien) : il faut faire la différence entre ce qui est commandes internes au langage (for, while, try/catch, def… j'ai eu un prof qui trollait contre new) et les opérations portant sur des objets manipulables : en orienté objet, la sortie standard est représentée par un objet pourvu de méthodes, et l'émission de texte ne peut sémantiquement pas être une commande interne, mais doit être un appel de méthode.

Dans un main en C, exit(0) et return 0 ont-ils le même sens ?

Dernière modification par ArkSeth (Le 15/06/2011, à 17:26)

grim7reaper · Le 15/06/2011, à 18:02

Pylade a écrit :

grim7reaper a écrit :
Pylade a écrit :
que les gens qui veulent faire du code propre ne devraient pas utiliser PHP…
Encore une fois, source !?
C'est pas dans mon lien en tout cas.
Y'a suffisemment de citation à l'encontre de PHP pour que tu n'ais pas à en inventer en plus…
Ben, la phrase du genre de celle qu’a lancée Tman. Mais ça n’est pas trouvé par les moteurs de recherche, donc ça ne devait pas être exactement ça…

Phrase qu'il a entendu de gens, qui l'ont probablement entendu de gens,…
Spa une source ça.
(oui j'ai rien de mieux à faire que de troller sur l'existence de cette citation )

ArkSeth a écrit :

Sinon, ce que j'ai contre les exceptions ?
Rien, si ce n'est que ce n'est pas toujours adapté. Ç'bien toi qui a une citation de défense des goto dans ta signature ? Bah le principe est le même : y a des moments où c'est adapté, et y en a d'autres ou ça l'est pas.

Tout à fait ! Utiliser les exceptions à tort et à travers c'est une mauvaise pratique.
C'est dans le nom en plus, les exceptions c'est pour les situations « exceptionnelles », pour les erreurs plus courantes/conventionnelles il vaut mieux utiliser les autres mécanismes. Les exceptions n'ont jamais eu vocation à supplanter ces mécanismes, elles sont là pour les compléter.

ArkSeth a écrit :

Non, je ne me suis effectivement jamais penché vraiment sur le Perl, mais il me semble que c'est précisément de lui que vient la distinction faite par PHP entre « + » et « . ».

Oui, ça vient bien de Perl.

ArkSeth a écrit :

si on se décidait à refaire un PHP en changeant l'interpréteur et en brisant la rétrocompatibilité juste sur une poignée de points, ça pourrait donner un truc très bien

C'est pas plus ou moins le but de PHP6 ça ?
Enfin c'est ce que j'ai cru comprendre.

tshirtman a écrit :

ils bricolent une sortie de flux (exactement le principe des exceptions) à un seul niveaux, par ce que le faire à plus serait suicidaire avec des goto…

T'entends quoi par « niveau » ?
Si c'est un goto qui saute en dehors d'une fonction c'est pas permis par le langage (bon après on peut utiliser setjmp/longjmp (ou sigsetjmp/siglongjmp), mais ça c'est le genre de fonction à manier avec des pinces modèle monseigneur…).

tshirtman a écrit :

après, je pense du mal du java, du C++, du php, du C#, du lisp, du erlang, du haskell… et même peut être de python (mais bon, pas beaucoup )

Ho ! Alors là, je veux bien que tu me montres tes reproches :]

Pylade a écrit :

l’inconsistance de l’ordre des arguments des fonctions d’IO

Heu c'est quoi le soucis là ?
Si c'est le fait de passer le FILE en premier, c'est pas plus con qu'autre chose. Tu dis où tu veux écrire avant de dire ce que tu veux écrire.
Le seul truc que l'on peut reprocher, c'est la différence d'ordre entre fputs et les autres.

Pylade a écrit :

Mais vérifier que deux variables ont le même type, ce n’est pas le rôle d’un opérateur de comparaison !

Bah si, tu testes une égalité (de type, certes) donc tu fais bien une comparaison. Donc c'est bien le boulot d'un opérateur de comparaison. Bien sûr, cet opérateur doit utiliser un symbole différent de l'opérateur traditionnel.

Pylade a écrit :

T’utilises deux implémentations différentes de la même interface en même temps ?

Bah comment dire, stun peu l'un des trucs les plus important venant de la POO ça (une interface/classe abstraite et des implémentations différentes derrière).

Pylade a écrit :

Je n’ai pas trop à me plaindre de GCC (quelques bugs, j’en ai trouvé trois, mais pas bien méchants).

À ce sujet, je me permet de te signaler que l'équipe de GCC est toujours en attente de tes rapports de bug

ArkSeth a écrit :

Dans un main en C, exit(0) et return 0 ont-ils le même sens ?

Non, la fonction exit appelle les fonctions enregistrées via atexit, return non.

Dernière modification par grim7reaper (Le 16/06/2011, à 05:40)

tshirtman · Le 15/06/2011, à 18:08

ArkSeth a écrit :

Question de cohérence : NaN ne convient pas aux fonctions autres que numériques. Or il m'apparaît plus judicieux d'avoir un comportement cohérent (renvoyer faux en cas d'erreur peut être utilisé dans tout un tas de cas), quitte à rajouter des cas possibles en plus pour les comportements spécifiques (genre une fonction de division renverrait false si on lui demande de diviser un truc non numérique, et NaN si on lui demande de diviser par zéro).
Après, c'est vrai que pour un langage comme PHP, on pourrait aussi inventer une autre constante particulière, qui correspondrait au retour d'erreur « standard ».

Voilà exactement le genre de questions sans réponses meilleure qu'une autre (toutes mauvaises) qu'on arrête de se poser quand on a une vraie gestion des erreurs, avec un type, et non un code, ton erreur à un nom, et peut être géré au niveau que tu veux, en fonction de ce nom, c'est infiniment supérieur au système de code de retour d'erreur… et si tu oublie de vérifier un code d'erreur, le programme ne détecte pas l'erreur (ou pas au bon moment, il plante juste plus tard, ou mange ton hamster), alors qu'une exception non géré remonte jusqu'a pouvoir dire "t'as pas pensé à ça, coco" et crasher ton programme au point exact de l'apparition du problème.

j'estime être objectif quand je dis qu'il y a des cas pour lesquels c'est préférable de ne pas balancer d'exceptions.

Uniquement si tu nous trouve un tel cas, sinon c'est juste des mots en l'air, pour défendre une position difficilement tenable, en espérant trouver un cas plus tard, une position que j'ai du mal a qualifier d'objective…

Quand tu ouvres l'interpréteur python et que tu tapes, par exemple, « 2 », c'est une chaîne de caractère qui est envoyée, mais elle est automatiquement castée en entier. Et donc quand tu tapes « 2 + i », si la variables i a précédemment été définie comme entière, tu demandes bien, techniquement, d'additionner un entier à une chaîne de caractères.

Il y a deux couches, le parser et l'interpréteur, si tu dit ça, tu nous dit "l'interpréteur quand il ouvre ton code source, il cast une chaine de charactères en object callable! truc de ouf" ça sent la mauvaise foi à plein nez, le prends pas mal…

Tu le demandes à l'interpréteur python, et il te fait les casts automatiques qui vont bien pour pouvoir effectuer l'opération. La seule différence avec PHP, c'est que PHP, qui se veut permissif, ne caste pas les arguments extérieurs dès leur réception (devoir différencier, dans le formulaire HTML, « 2 » et « "2" » comme on le fait dans l'interpréteur python, ce serait quand même sacrément lourd), et permet donc de les autocaster en interne.

C'est sur que c'est lourd de faire int(request.params['truc']) + 42 au lieu de request.params['truc'] + 42, et c'est vrai, ça pourrait lever une exception et faire planter notre programme si c'est pas un entier et qu'on le gère pas! truc de ouf, c'est vrai qu'en php ont fait pas "if (is_integer($POST['truc'])) then…"… et si on oublie de le faire, on a juste des résultats inconsistents, et rien pour nous prévenir… c'est pas grave, c'est tellement plus simple…

En PHP aussi, on a une opération avec du sens. Pas dénuée de bugs, manifestement, mais je répète encore une fois qu'il faut (même si ce n'est pas forcément évident avec un interpréteur de référence comme ça) distinguer la critique du langage de celle de son implémentation.

Non, ce n'est pas un bug, c'est le résultat de "on fait tout pour que l'opération réussisse, quitte a bricoler sérieusement avec les données" que php prone avec son typage plus faible qu'un paraplégique anémique myopathe… et c'est une source de bug, mais c'est tout à fait cohérent avec la logique du langage, donc selon toi, il n'y a rien à y reprocher…

Tu peux régler cet « alias » pour qu'il pointe sur autre chose ? Et qu'entends-tu par « en proposant quelques opérations en plus », exactement ?
J'suppose que si on voit ça comme un genre de variable autodéclarée pointant vers une méthode précise d'un objet précis, et pas comme une commande à part, ça peut être recevable…

Hum, tu peux assigner quelque chose à print, mais tu ne pourras pas lui donner le même type de sémantique que le reste du langage, ce sera une fonction, pas un mot clé…

Concernant le troll de tshirtman que je vois juste à temps en prévisualisant (prévisualiser, saybien) : il faut faire la différence entre ce qui est commandes internes au langage (for, while, try/catch, def… j'ai eu un prof qui trollait contre new) et les opérations portant sur des objets manipulables : en orienté objet, la sortie standard est représentée par un objet pourvu de méthodes, et l'émission de texte ne peut sémantiquement pas être une commande interne, mais doit être un appel de méthode.

y'a sys.out hein… qui est un objet de type fichier…

tshirtman · Le 15/06/2011, à 18:16

grim7reaper a écrit :

Tout à fait ! Utiliser les exceptions à tort et à travers c'est une mauvaise pratique.
C'est dans le nom en plus, les exceptions c'est pour les situations « exceptionnelles », pour les erreurs plus courantes/conventionnelles il vaut mieux utiliser les autres mécanismes. Les exceptions n'ont jamais eu vocation à supplanter ces mécanismes, elles sont là pour les compléter.

Ben pour moi elles unifient très bien toutes les gestion d'erreurs possibles… après, c'est une erreur qui doit être exceptionelle, on va pas utiliser des exceptions comme base pour gérer le flux de son programme…

tshirtman a écrit :
ils bricolent une sortie de flux (exactement le principe des exceptions) à un seul niveaux, par ce que le faire à plus serait suicidaire avec des goto…
T'entends quoi par « niveau » ?
Si c'est un goto qui saute en dehors d'une fonction c'est pas permis par le langage (bon après on peut utiliser setjmp/longjmp (ou sigsetjmp/siglongjmp), mais ça c'est le genre de fonction à manier avec des pinces modèle monseigneur…).

Ah oui, j'avais oublié que le goto en C était de toutes façons un peu sain d'esprit… on ne sort pas de la fonction… bon ben voilà, les exceptions permettent de faire ça en remontant dans les fonctions appelantes, jusqu'a trouver une procédure de "sortie de crise" correspondante à l'erreur rencontré, et ce sans risque de se planter dans la gestion de la sortie de flux, c'est géré mécaniquement.

tshirtman a écrit :
après, je pense du mal du java, du C++, du php, du C#, du lisp, du erlang, du haskell… et même peut être de python (mais bon, pas beaucoup )
Ho ! Alors là, je veux bien que tu me montres tes reproches :]

j'ai dit "peut être"

(j'y réfléchirai, on peut reprocher des choses à la non mutabilité des chaines de charactères, des trucs du genre, mais rien de trop méchant, je crois )

grim7reaper · Le 15/06/2011, à 18:36

tshirtman a écrit :

grim7reaper a écrit :
Tout à fait ! Utiliser les exceptions à tort et à travers c'est une mauvaise pratique.
C'est dans le nom en plus, les exceptions c'est pour les situations « exceptionnelles », pour les erreurs plus courantes/conventionnelles il vaut mieux utiliser les autres mécanismes. Les exceptions n'ont jamais eu vocation à supplanter ces mécanismes, elles sont là pour les compléter.
Ben pour moi elles unifient très bien toutes les gestion d'erreurs possibles… après, c'est une erreur qui doit être exceptionelle, on va pas utiliser des exceptions comme base pour gérer le flux de son programme…

Si tu savais ce que j'ai vu parfois (cassage de boucle à la goto, émulation d'un return qui traverse plusieurs fonctions pour renvoyer une valeur et autres abominations du genre…).

Nan mais les exceptions c'est bien mais ça amène aussi des emmerdes (d'où l'intérêt de pas en foutre partout).
Faut bien faire gaffe à ce que le code qui les utilisent soient exception‑safe (ok, la problématique est moins présente dans les langages avec GC mais elle existe quand même). Je sais qu'il « suffit » d'appliquer l'idiome RAII mais c'est parfois plus facile à dire qu'à faire.

Et puis ça implique un coût non négligeable à l'exécution et même, mais dans une moindre mesure, quand aucune exception n'est lancée !
Ok, les perf' on s'en fiche en général (surtout si on fait du Python ou du Java), mais quand c'est important et bien il vaut parfois mieux se passer des exceptions.

Dernière modification par grim7reaper (Le 15/06/2011, à 18:37)

tshirtman · Le 15/06/2011, à 19:48

Bah, comme toutes les bonnes choses, les exceptions peuvent être abusées, moi aussi j'ai déjà pensé à utiliser les exceptions pour remonter des résultats à plusieurs niveaux, mais j'ai jamais été malade au point de le faire… une erreur, ok, mais un résultat, ça montre un vrai soucis de conception…

Rolinh · Le 15/06/2011, à 22:04

Et ben... vous êtes productifs en ce moment!
Je prendrais le temps de lire tout ça demain, quand j'aurais finis mon dernier examen (programmation système).

Je suis justement en train de revoir les optimisations en C et ça me fait direct penser à grim ^^

grim7reaper · Le 15/06/2011, à 22:09

Rolinh a écrit :

Et ben... vous êtes productifs en ce moment!

Faut croire que PHP est une source d'inspiration ^^"

Rolinh a écrit :

Je prendrais le temps de lire tout ça demain, quand j'aurais finis mon dernier examen (programmation système).

Bon courage !

Rolinh a écrit :

Je suis justement en train de revoir les optimisations en C et ça me fait direct penser à grim ^^

Hum c'est bizarre ça, je ne vois vraiment pas pourquoi
C'est quoi les optimisations en question ?

Allez, BN World!

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#251 Le 15/06/2011, à 10:03

Re : /* Topic des codeurs couche-tard [5] */

#252 Le 15/06/2011, à 12:30

Re : /* Topic des codeurs couche-tard [5] */

#253 Le 15/06/2011, à 12:38

Re : /* Topic des codeurs couche-tard [5] */

#254 Le 15/06/2011, à 12:47

Re : /* Topic des codeurs couche-tard [5] */

#255 Le 15/06/2011, à 12:48

Re : /* Topic des codeurs couche-tard [5] */

#256 Le 15/06/2011, à 12:59

Re : /* Topic des codeurs couche-tard [5] */

#257 Le 15/06/2011, à 13:02

Re : /* Topic des codeurs couche-tard [5] */

#258 Le 15/06/2011, à 13:30

Re : /* Topic des codeurs couche-tard [5] */

#259 Le 15/06/2011, à 13:40

Re : /* Topic des codeurs couche-tard [5] */

#260 Le 15/06/2011, à 14:00

Re : /* Topic des codeurs couche-tard [5] */

#261 Le 15/06/2011, à 14:32

Re : /* Topic des codeurs couche-tard [5] */

#262 Le 15/06/2011, à 14:40

Re : /* Topic des codeurs couche-tard [5] */

#263 Le 15/06/2011, à 14:49

Re : /* Topic des codeurs couche-tard [5] */

#264 Le 15/06/2011, à 16:02

Re : /* Topic des codeurs couche-tard [5] */

#265 Le 15/06/2011, à 16:19

Re : /* Topic des codeurs couche-tard [5] */

#266 Le 15/06/2011, à 16:27

Re : /* Topic des codeurs couche-tard [5] */

#267 Le 15/06/2011, à 16:29

Re : /* Topic des codeurs couche-tard [5] */

#268 Le 15/06/2011, à 17:21

Re : /* Topic des codeurs couche-tard [5] */

#269 Le 15/06/2011, à 18:02

Re : /* Topic des codeurs couche-tard [5] */

#270 Le 15/06/2011, à 18:08

Re : /* Topic des codeurs couche-tard [5] */

#271 Le 15/06/2011, à 18:16

Re : /* Topic des codeurs couche-tard [5] */

#272 Le 15/06/2011, à 18:36

Re : /* Topic des codeurs couche-tard [5] */

#273 Le 15/06/2011, à 19:48

Re : /* Topic des codeurs couche-tard [5] */

#274 Le 15/06/2011, à 22:04

Re : /* Topic des codeurs couche-tard [5] */

#275 Le 15/06/2011, à 22:09

Re : /* Topic des codeurs couche-tard [5] */

Pied de page des forums