outre divers cas de timtowtdi pour de l'heritage multiple, des cas :
- parseur tolerant de type xml/html/sgml ou tous mes tokens sont blesée standalone, puis reclassé en open si un close est trouvé ( et resolution des fermetures necessaire pour l'obtenir ).
- interpreteur : une instruction "X" générique doit prendre un comportement contextuel connu a l'éxecution selon si l'instruction "Y" ou "Z" a été executé correctement, je change la classe du noeud dans mon arbre d'execution et donc change le comportement de mon noeud. le gros interet est pour choisir la bonne execution pour un noeud qui en a plusieurs possible mais seulement une executable.
- gestion de protocole : cas SMTP / ESMTP : tu as les rfc 821 / 2821, la difference se declare dans le EHLO ou HELO mais les commandes ne sont pas les memes ce qui fait que mon interpreteur doit pouvoir changer de mode si quand il est en 2821 il recoit du 821 ou le contraire.
je ne suis pas un adepte des IF et je comprend le propos de Dijkstra comme si le goto est harmful, et qu'il ne peut y avoir au plus qu'un goto inconditionnel utile, ce qui est harmful dans le goto c'est la condition sous jacente. a partir de là, le bless de perl a tous sont interet.
sinon, on est d'accord python est assez pauvre comme langage ...
"There is only one way to do it" ai je lu a son sujet, c'est comme si il n'y avait que le missionnaire comme position possible ou qu'une seule maniere de penser les chose. on retrouve la meme approche dans java.
d'un autre coté, on retrouve aussi cela à l'école avec 2+2=4, ou la racine carré de -1 n'existe pas, ou il n'y a qu'un infini, ... donc bon, il en faut pour tous les gouts c'est ce qui fait la richesse de l'humanite.
mais bizarrement, ce n'est pas parce qu'il n'y a qu'une seule solution que tout le monde va y arriver, cela part d'une sous evaluation colossale de l'imagination de l'etre humain.
[^] # Re: Heu, perl ?
Posté par Mouns . En réponse au message Qui m'aime me suive !!. Évalué à 3.
- parseur tolerant de type xml/html/sgml ou tous mes tokens sont blesée standalone, puis reclassé en open si un close est trouvé ( et resolution des fermetures necessaire pour l'obtenir ).
- interpreteur : une instruction "X" générique doit prendre un comportement contextuel connu a l'éxecution selon si l'instruction "Y" ou "Z" a été executé correctement, je change la classe du noeud dans mon arbre d'execution et donc change le comportement de mon noeud. le gros interet est pour choisir la bonne execution pour un noeud qui en a plusieurs possible mais seulement une executable.
- gestion de protocole : cas SMTP / ESMTP : tu as les rfc 821 / 2821, la difference se declare dans le EHLO ou HELO mais les commandes ne sont pas les memes ce qui fait que mon interpreteur doit pouvoir changer de mode si quand il est en 2821 il recoit du 821 ou le contraire.
je ne suis pas un adepte des IF et je comprend le propos de Dijkstra comme si le goto est harmful, et qu'il ne peut y avoir au plus qu'un goto inconditionnel utile, ce qui est harmful dans le goto c'est la condition sous jacente. a partir de là, le bless de perl a tous sont interet.
sinon, on est d'accord python est assez pauvre comme langage ...
"There is only one way to do it" ai je lu a son sujet, c'est comme si il n'y avait que le missionnaire comme position possible ou qu'une seule maniere de penser les chose. on retrouve la meme approche dans java.
d'un autre coté, on retrouve aussi cela à l'école avec 2+2=4, ou la racine carré de -1 n'existe pas, ou il n'y a qu'un infini, ... donc bon, il en faut pour tous les gouts c'est ce qui fait la richesse de l'humanite.
mais bizarrement, ce n'est pas parce qu'il n'y a qu'une seule solution que tout le monde va y arriver, cela part d'une sous evaluation colossale de l'imagination de l'etre humain.