([^{]*) = un nombre quelconque de fois ce qui n'est pas un ou un { (ou peut-être seulement un { mais j'ai la flemme d'aller vérifier)
.* = un nombre quelconque de fois ce qui n'est pas un saut de ligne
([^}]*) = un nombre quelconque de fois ce qui n'est pas un ou un } (même remarque)
$ = ancré à la fin
mais ça me donne l'entiéreté de la fonction, avec son corps...
Oui, parce que le premier saut de ligne se trouvait juste après la première accolade, donc le .* était vide. Note que dans le cas contraire c'est RegExp.$2 qui aurait été vide.
Le problème c'est que l'option s qui autorise le caractère . à remplacer un saut de ligne n'existe pas dans JavaScript (c'est dans PCRE). Ceci devrait fonctionner :
fonction = fonction.replace(/^([^{]*)(.|n)*([^}]*)$/, RegExp.$1+'{...}'+RegExp.$3);
Mais il y a plus simple, par exemple :
fonction = fonction.replace(/{(.|n)*/, '{...}');
le but de la manip:
convertir :
function Machin(){
...
corps de la onction
...
}
en :
function Machin(){...} //là les "..." remplacent ce qu'il y avait dans
le corps de la fonction.
Donc tu veux garder tout jusqu'à l'accolade ouvrante, et remplacer tout
le reste par "...}".
j'ai essayé des trucs comme :
var fonction=setToRed.toString();// "setRed" est une function
([^{]*) = un nombre quelconque de fois ce qui n'est pas un ou un {
(ou peut-être seulement un { mais j'ai la flemme d'aller vérifier)
.* = un nombre quelconque de fois ce qui n'est pas un saut de ligne
([^}]*) = un nombre quelconque de fois ce qui n'est pas un ou un }
(même remarque)
$ = ancré à la fin
mais ça me donne l'entiéreté de la fonction, avec son corps...
Oui, parce que le premier saut de ligne se trouvait juste après la
première accolade, donc le .* était vide. Note que dans le cas contraire
c'est RegExp.$2 qui aurait été vide.
Le problème c'est que l'option s qui autorise le caractère . à remplacer
un saut de ligne n'existe pas dans JavaScript (c'est dans PCRE). Ceci
devrait fonctionner :
fonction = fonction.replace(/^([^{]*)(.|n)*([^}]*)$/,
RegExp.$1+'{...}'+RegExp.$3);
([^{]*) = un nombre quelconque de fois ce qui n'est pas un ou un { (ou peut-être seulement un { mais j'ai la flemme d'aller vérifier)
.* = un nombre quelconque de fois ce qui n'est pas un saut de ligne
([^}]*) = un nombre quelconque de fois ce qui n'est pas un ou un } (même remarque)
$ = ancré à la fin
mais ça me donne l'entiéreté de la fonction, avec son corps...
Oui, parce que le premier saut de ligne se trouvait juste après la première accolade, donc le .* était vide. Note que dans le cas contraire c'est RegExp.$2 qui aurait été vide.
Le problème c'est que l'option s qui autorise le caractère . à remplacer un saut de ligne n'existe pas dans JavaScript (c'est dans PCRE). Ceci devrait fonctionner :
fonction = fonction.replace(/^([^{]*)(.|n)*([^}]*)$/, RegExp.$1+'{...}'+RegExp.$3);
Mais il y a plus simple, par exemple :
fonction = fonction.replace(/{(.|n)*/, '{...}');
unbewusst.sein
Olivier Miakinen <om+ wrote:
Donc tu veux garder tout jusqu'à l'accolade ouvrante, et remplacer tout le reste par "...}".
exactement, c'est pour un "toString()" sur des objets quelconques... ça n'a d'intérêt que pour la mise au point...
j'ai essayé des trucs comme :
var fonction=setToRed.toString();// "setRed" est une function
([^{]*) = un nombre quelconque de fois ce qui n'est pas un ou un { (ou peut-être seulement un { mais j'ai la flemme d'aller vérifier)
c'est ce que j'ai pensé le était là pour "escaper" le { qui est un caractère spécial en Regexp.
mais ça me donne l'entiéreté de la fonction, avec son corps...
Oui, parce que le premier saut de ligne se trouvait juste après la première accolade, donc le .* était vide. Note que dans le cas contraire c'est RegExp.$2 qui aurait été vide.
Le problème c'est que l'option s qui autorise le caractère . à remplacer un saut de ligne n'existe pas dans JavaScript (c'est dans PCRE). Ceci devrait fonctionner :
ouais exact, j'ai recherché, vainement, ce modifieur.
fonction = fonction.replace(/^([^{]*)(.|n)*([^}]*)$/, RegExp.$1+'{...}'+RegExp.$3);
Mais il y a plus simple, par exemple :
fonction = fonction.replace(/{(.|n)*/, '{...}');
oui, merci beaucoup, ça roule super...
-- Une Bévue
Olivier Miakinen <om+news@miakinen.net> wrote:
Donc tu veux garder tout jusqu'à l'accolade ouvrante, et remplacer tout
le reste par "...}".
exactement, c'est pour un "toString()" sur des objets quelconques...
ça n'a d'intérêt que pour la mise au point...
j'ai essayé des trucs comme :
var fonction=setToRed.toString();// "setRed" est une function
([^{]*) = un nombre quelconque de fois ce qui n'est pas un ou un {
(ou peut-être seulement un { mais j'ai la flemme d'aller vérifier)
c'est ce que j'ai pensé le était là pour "escaper" le { qui est un
caractère spécial en Regexp.
mais ça me donne l'entiéreté de la fonction, avec son corps...
Oui, parce que le premier saut de ligne se trouvait juste après la
première accolade, donc le .* était vide. Note que dans le cas contraire
c'est RegExp.$2 qui aurait été vide.
Le problème c'est que l'option s qui autorise le caractère . à remplacer
un saut de ligne n'existe pas dans JavaScript (c'est dans PCRE). Ceci
devrait fonctionner :
ouais exact, j'ai recherché, vainement, ce modifieur.
fonction = fonction.replace(/^([^{]*)(.|n)*([^}]*)$/,
RegExp.$1+'{...}'+RegExp.$3);
([^{]*) = un nombre quelconque de fois ce qui n'est pas un ou un { (ou peut-être seulement un { mais j'ai la flemme d'aller vérifier)
c'est ce que j'ai pensé le était là pour "escaper" le { qui est un caractère spécial en Regexp.
mais ça me donne l'entiéreté de la fonction, avec son corps...
Oui, parce que le premier saut de ligne se trouvait juste après la première accolade, donc le .* était vide. Note que dans le cas contraire c'est RegExp.$2 qui aurait été vide.
Le problème c'est que l'option s qui autorise le caractère . à remplacer un saut de ligne n'existe pas dans JavaScript (c'est dans PCRE). Ceci devrait fonctionner :
ouais exact, j'ai recherché, vainement, ce modifieur.
fonction = fonction.replace(/^([^{]*)(.|n)*([^}]*)$/, RegExp.$1+'{...}'+RegExp.$3);
Mais il y a plus simple, par exemple :
fonction = fonction.replace(/{(.|n)*/, '{...}');
oui, merci beaucoup, ça roule super...
-- Une Bévue
unbewusst.sein
Une Bévue wrote:
oui, merci beaucoup, ça roule super...
Euh, un "petit bémol" : ma function est exactement écrite comme ça : function setToRed(element){ element.style.backgroundColor='red'; }
avec fonction = fonction.replace(/{(.|n)*/, '{...}');, ça me retourne : function setToRed(element) {...}
donc avec un n entre (element) et {...}, j'aurais préféré : function setToRed(element) {...} (même ligne)
je ne pige pas pourquoi (c'est surtout pour ma comprenotte) le n derrière l'acolade ouvrante {.
j'ai essayé en escapant ({) : fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi... -- Une Bévue
Une Bévue <unbewusst.sein@weltanschauung.com.invalid> wrote:
oui, merci beaucoup, ça roule super...
Euh, un "petit bémol" :
ma function est exactement écrite comme ça :
function setToRed(element){
element.style.backgroundColor='red';
}
avec fonction = fonction.replace(/{(.|n)*/, '{...}');, ça me retourne :
function setToRed(element)
{...}
donc avec un n entre (element) et {...}, j'aurais préféré :
function setToRed(element) {...} (même ligne)
je ne pige pas pourquoi (c'est surtout pour ma comprenotte) le n
derrière l'acolade ouvrante {.
j'ai essayé en escapant ({) :
fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi...
--
Une Bévue
Euh, un "petit bémol" : ma function est exactement écrite comme ça : function setToRed(element){ element.style.backgroundColor='red'; }
avec fonction = fonction.replace(/{(.|n)*/, '{...}');, ça me retourne : function setToRed(element) {...}
donc avec un n entre (element) et {...}, j'aurais préféré : function setToRed(element) {...} (même ligne)
je ne pige pas pourquoi (c'est surtout pour ma comprenotte) le n derrière l'acolade ouvrante {.
j'ai essayé en escapant ({) : fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi... -- Une Bévue
Olivier Miakinen
Une Bévue wrote:
oui, merci beaucoup, ça roule super...
Euh, un "petit bémol" : ma function est exactement écrite comme ça : function setToRed(element){ element.style.backgroundColor='red'; }
avec fonction = fonction.replace(/{(.|n)*/, '{...}');, ça me retourne : function setToRed(element) {...}
As-tu regardé à quoi ressemble fonction après le toString() et avant le replace() ? Il est probable que l'accolade est à la ligne suivante, présentation la plus fréquente pour les fonctions définies sur plusieurs lignes.
j'ai essayé en escapant ({) :
Pfff... c'est exactement comme de rajouter un dans la classe de caractères : comme tu ne sais pas ce que tu fais, tu es peut-être en train de rajouter un bug car dans certains langages le n'est pas supprimé quand il est inutile. Et surtout cela obscurcit le code.
fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi...
Ce qui est sûr c'est que ça ne pouvait pas arranger les choses, juste les dégrader (tu aurais retrouvé la fonction complète).
Ayant compris qu'il y a un saut de ligne tu peux faire : fonction = fonction.replace(/n(.|n)*/, '{...}');
Une Bévue <unbewusst.sein@weltanschauung.com.invalid> wrote:
oui, merci beaucoup, ça roule super...
Euh, un "petit bémol" :
ma function est exactement écrite comme ça :
function setToRed(element){
element.style.backgroundColor='red';
}
avec fonction = fonction.replace(/{(.|n)*/, '{...}');, ça me retourne :
function setToRed(element)
{...}
As-tu regardé à quoi ressemble fonction après le toString() et avant le
replace() ? Il est probable que l'accolade est à la ligne suivante,
présentation la plus fréquente pour les fonctions définies sur plusieurs
lignes.
j'ai essayé en escapant ({) :
Pfff... c'est exactement comme de rajouter un dans la classe de
caractères : comme tu ne sais pas ce que tu fais, tu es peut-être en
train de rajouter un bug car dans certains langages le n'est pas
supprimé quand il est inutile. Et surtout cela obscurcit le code.
fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi...
Ce qui est sûr c'est que ça ne pouvait pas arranger les choses, juste
les dégrader (tu aurais retrouvé la fonction complète).
Ayant compris qu'il y a un saut de ligne tu peux faire :
fonction = fonction.replace(/n(.|n)*/, '{...}');
Euh, un "petit bémol" : ma function est exactement écrite comme ça : function setToRed(element){ element.style.backgroundColor='red'; }
avec fonction = fonction.replace(/{(.|n)*/, '{...}');, ça me retourne : function setToRed(element) {...}
As-tu regardé à quoi ressemble fonction après le toString() et avant le replace() ? Il est probable que l'accolade est à la ligne suivante, présentation la plus fréquente pour les fonctions définies sur plusieurs lignes.
j'ai essayé en escapant ({) :
Pfff... c'est exactement comme de rajouter un dans la classe de caractères : comme tu ne sais pas ce que tu fais, tu es peut-être en train de rajouter un bug car dans certains langages le n'est pas supprimé quand il est inutile. Et surtout cela obscurcit le code.
fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi...
Ce qui est sûr c'est que ça ne pouvait pas arranger les choses, juste les dégrader (tu aurais retrouvé la fonction complète).
Ayant compris qu'il y a un saut de ligne tu peux faire : fonction = fonction.replace(/n(.|n)*/, '{...}');
unbewusst.sein
Olivier Miakinen <om+ wrote:
As-tu regardé à quoi ressemble fonction après le toString() et avant le replace() ? Il est probable que l'accolade est à la ligne suivante, présentation la plus fréquente pour les fonctions définies sur plusieurs lignes.
Ah ZUT ! effectivement.... mea culpa ;-)
le toString() me sort cette forme : function setToRed(element) { element.style.backgroundColor = "red"; }
d'où le n...
j'ai essayé en escapant ({) :
Pfff... c'est exactement comme de rajouter un dans la classe de caractères : comme tu ne sais pas ce que tu fais, tu es peut-être en train de rajouter un bug car dans certains langages le n'est pas supprimé quand il est inutile. Et surtout cela obscurcit le code.
euh c'est ce que j'avais retenu "{" est un métacaractère non ?
fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi...
Ce qui est sûr c'est que ça ne pouvait pas arranger les choses, juste les dégrader (tu aurais retrouvé la fonction complète).
Ayant compris qu'il y a un saut de ligne tu peux faire : fonction = fonction.replace(/n(.|n)*/, '{...}');
OK, ça roule -- Une Bévue
Olivier Miakinen <om+news@miakinen.net> wrote:
As-tu regardé à quoi ressemble fonction après le toString() et avant le
replace() ? Il est probable que l'accolade est à la ligne suivante,
présentation la plus fréquente pour les fonctions définies sur plusieurs
lignes.
Ah ZUT ! effectivement....
mea culpa ;-)
le toString() me sort cette forme :
function setToRed(element)
{
element.style.backgroundColor = "red";
}
d'où le n...
j'ai essayé en escapant ({) :
Pfff... c'est exactement comme de rajouter un dans la classe de
caractères : comme tu ne sais pas ce que tu fais, tu es peut-être en
train de rajouter un bug car dans certains langages le n'est pas
supprimé quand il est inutile. Et surtout cela obscurcit le code.
euh c'est ce que j'avais retenu "{" est un métacaractère non ?
fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi...
Ce qui est sûr c'est que ça ne pouvait pas arranger les choses, juste
les dégrader (tu aurais retrouvé la fonction complète).
Ayant compris qu'il y a un saut de ligne tu peux faire :
fonction = fonction.replace(/n(.|n)*/, '{...}');
As-tu regardé à quoi ressemble fonction après le toString() et avant le replace() ? Il est probable que l'accolade est à la ligne suivante, présentation la plus fréquente pour les fonctions définies sur plusieurs lignes.
Ah ZUT ! effectivement.... mea culpa ;-)
le toString() me sort cette forme : function setToRed(element) { element.style.backgroundColor = "red"; }
d'où le n...
j'ai essayé en escapant ({) :
Pfff... c'est exactement comme de rajouter un dans la classe de caractères : comme tu ne sais pas ce que tu fais, tu es peut-être en train de rajouter un bug car dans certains langages le n'est pas supprimé quand il est inutile. Et surtout cela obscurcit le code.
euh c'est ce que j'avais retenu "{" est un métacaractère non ?
fonction = fonction.replace(/{(.|n)*/, '{...}');
ça donne exactement le même résultat curieux pour moi...
Ce qui est sûr c'est que ça ne pouvait pas arranger les choses, juste les dégrader (tu aurais retrouvé la fonction complète).
Ayant compris qu'il y a un saut de ligne tu peux faire : fonction = fonction.replace(/n(.|n)*/, '{...}');
OK, ça roule -- Une Bévue
Olivier Miakinen
"{" est un métacaractère non ?
Non. En tout cas pas tout seul, et encore moins dans une classe de caractères. Par ailleurs, il n'y a aucune équivalence entre « être un métacaractère » et « changer de sens quand on le précède de ». Cf. le caractère n, par exemple ; dirais-tu que n est un métacaractère ?
Mais surtout, si tu rajoutes un devant un caractère qui n'en a pas besoin, parfois ça supprime le sans rien dire et parfois ça le laisse, selon le langage utilisé. Or, comme tu n'as pas l'air de vouloir lire les docs avant de faire quelque chose, tu vas un jour te retrouver dans un cas où ce qui fonctionnait en XXX¹ ne fonctionnera plus en YYY, et tu viendras râler dans le groupe correspondant parce que ce n'est pas logique.
¹ Remplacer XXX et YYY par des langages au hasard : JavaScript, PHP, C, Perl, Python, Java, etc.
"{" est un métacaractère non ?
Non. En tout cas pas tout seul, et encore moins dans une classe de
caractères. Par ailleurs, il n'y a aucune équivalence entre « être un
métacaractère » et « changer de sens quand on le précède de ». Cf. le
caractère n, par exemple ; dirais-tu que n est un métacaractère ?
Mais surtout, si tu rajoutes un devant un caractère qui n'en a pas
besoin, parfois ça supprime le sans rien dire et parfois ça le laisse,
selon le langage utilisé. Or, comme tu n'as pas l'air de vouloir lire
les docs avant de faire quelque chose, tu vas un jour te retrouver dans
un cas où ce qui fonctionnait en XXX¹ ne fonctionnera plus en YYY, et
tu viendras râler dans le groupe correspondant parce que ce n'est pas
logique.
¹ Remplacer XXX et YYY par des langages au hasard : JavaScript, PHP, C,
Perl, Python, Java, etc.
Non. En tout cas pas tout seul, et encore moins dans une classe de caractères. Par ailleurs, il n'y a aucune équivalence entre « être un métacaractère » et « changer de sens quand on le précède de ». Cf. le caractère n, par exemple ; dirais-tu que n est un métacaractère ?
Mais surtout, si tu rajoutes un devant un caractère qui n'en a pas besoin, parfois ça supprime le sans rien dire et parfois ça le laisse, selon le langage utilisé. Or, comme tu n'as pas l'air de vouloir lire les docs avant de faire quelque chose, tu vas un jour te retrouver dans un cas où ce qui fonctionnait en XXX¹ ne fonctionnera plus en YYY, et tu viendras râler dans le groupe correspondant parce que ce n'est pas logique.
¹ Remplacer XXX et YYY par des langages au hasard : JavaScript, PHP, C, Perl, Python, Java, etc.
unbewusst.sein
Olivier Miakinen <om+ wrote:
Non. En tout cas pas tout seul, et encore moins dans une classe de caractères. Par ailleurs, il n'y a aucune équivalence entre « être un métacaractère » et « changer de sens quand on le précède de ». Cf. le caractère n, par exemple ; dirais-tu que n est un métacaractère ?
non, pour moi, c'est juste un moyen de représenter un caractère "non imprimable".
Mais surtout, si tu rajoutes un devant un caractère qui n'en a pas besoin, parfois ça supprime le sans rien dire et parfois ça le laisse, selon le langage utilisé.
je n'ai pas rencontré ce pb, si mon souvenir est bon, en java et en ruby.
Or, comme tu n'as pas l'air de vouloir lire les docs avant de faire quelque chose,
amha, on ne se réfère à la doc que quand il y a un pb, il faut se poser des questions, avoir rencontré un problème, pour aller lire une doc, plutôt mal faite en ce qui concerne le "web", bien souvent on (je) fonctionne par analogie d'un langage à un autre.
j'ai cherché mais je n'ai pas trouvé cette info précise ni dans le "Ecma-262.pdf" ni dans le "CoreReferenceJS15". je chercherai ailleurs sur le net.
soit dit en passant je doute que Ecma-262.pdf soit une docum faite pour l'utilisateur de js, c'est plutôt une spec écrite pour ceux, sans doute très peu nombreux, qui implémentent js dans les naviagteurs.
tu vas un jour te retrouver dans un cas où ce qui fonctionnait en XXX? ne fonctionnera plus en YYY, et tu viendras râler dans le groupe correspondant parce que ce n'est pas logique.
je sais bien que tous les regex sont -- peu ou prou -- des dialectes, à mon grand regret.
je ne prend pas des regex toutes faites en prog en xxx vers un autre en yyy, comme je ne me sent pas sûr en regexp je teste.
-- Une Bévue
Olivier Miakinen <om+news@miakinen.net> wrote:
Non. En tout cas pas tout seul, et encore moins dans une classe de
caractères. Par ailleurs, il n'y a aucune équivalence entre « être un
métacaractère » et « changer de sens quand on le précède de ». Cf. le
caractère n, par exemple ; dirais-tu que n est un métacaractère ?
non, pour moi, c'est juste un moyen de représenter un caractère "non
imprimable".
Mais surtout, si tu rajoutes un devant un caractère qui n'en a pas
besoin, parfois ça supprime le sans rien dire et parfois ça le laisse,
selon le langage utilisé.
je n'ai pas rencontré ce pb, si mon souvenir est bon, en java et en
ruby.
Or, comme tu n'as pas l'air de vouloir lire
les docs avant de faire quelque chose,
amha, on ne se réfère à la doc que quand il y a un pb, il faut se poser
des questions, avoir rencontré un problème, pour aller lire une doc,
plutôt mal faite en ce qui concerne le "web", bien souvent on (je)
fonctionne par analogie d'un langage à un autre.
j'ai cherché mais je n'ai pas trouvé cette info précise ni dans le
"Ecma-262.pdf" ni dans le "CoreReferenceJS15". je chercherai ailleurs
sur le net.
soit dit en passant je doute que Ecma-262.pdf soit une docum faite pour
l'utilisateur de js, c'est plutôt une spec écrite pour ceux, sans doute
très peu nombreux, qui implémentent js dans les naviagteurs.
tu vas un jour te retrouver dans
un cas où ce qui fonctionnait en XXX? ne fonctionnera plus en YYY, et
tu viendras râler dans le groupe correspondant parce que ce n'est pas
logique.
je sais bien que tous les regex sont -- peu ou prou -- des dialectes, à
mon grand regret.
je ne prend pas des regex toutes faites en prog en xxx vers un autre en
yyy, comme je ne me sent pas sûr en regexp je teste.
Non. En tout cas pas tout seul, et encore moins dans une classe de caractères. Par ailleurs, il n'y a aucune équivalence entre « être un métacaractère » et « changer de sens quand on le précède de ». Cf. le caractère n, par exemple ; dirais-tu que n est un métacaractère ?
non, pour moi, c'est juste un moyen de représenter un caractère "non imprimable".
Mais surtout, si tu rajoutes un devant un caractère qui n'en a pas besoin, parfois ça supprime le sans rien dire et parfois ça le laisse, selon le langage utilisé.
je n'ai pas rencontré ce pb, si mon souvenir est bon, en java et en ruby.
Or, comme tu n'as pas l'air de vouloir lire les docs avant de faire quelque chose,
amha, on ne se réfère à la doc que quand il y a un pb, il faut se poser des questions, avoir rencontré un problème, pour aller lire une doc, plutôt mal faite en ce qui concerne le "web", bien souvent on (je) fonctionne par analogie d'un langage à un autre.
j'ai cherché mais je n'ai pas trouvé cette info précise ni dans le "Ecma-262.pdf" ni dans le "CoreReferenceJS15". je chercherai ailleurs sur le net.
soit dit en passant je doute que Ecma-262.pdf soit une docum faite pour l'utilisateur de js, c'est plutôt une spec écrite pour ceux, sans doute très peu nombreux, qui implémentent js dans les naviagteurs.
tu vas un jour te retrouver dans un cas où ce qui fonctionnait en XXX? ne fonctionnera plus en YYY, et tu viendras râler dans le groupe correspondant parce que ce n'est pas logique.
je sais bien que tous les regex sont -- peu ou prou -- des dialectes, à mon grand regret.
je ne prend pas des regex toutes faites en prog en xxx vers un autre en yyy, comme je ne me sent pas sûr en regexp je teste.
-- Une Bévue
Olivier Miakinen
amha, on ne se réfère à la doc que quand il y a un pb, il faut se poser des questions, avoir rencontré un problème, pour aller lire une doc, plutôt mal faite en ce qui concerne le "web", bien souvent on (je) fonctionne par analogie d'un langage à un autre.
Oui, je vois que nos deux approches de la programmation sont très différentes. Personnellement je préfère lire la doc avant et avoir un code qui marche du premier coup, plutôt que de passer du temps après coup pour débuguer. Aussi, lorsque je dois débuguer le code de quelqu'un d'autre, je le fais le plus possible en lisant le code (donc sans l'exécuter) au lieu de procéder par essais et erreurs(¹).
[...]
soit dit en passant je doute que Ecma-262.pdf soit une docum faite pour l'utilisateur de js, c'est plutôt une spec écrite pour ceux, sans doute très peu nombreux, qui implémentent js dans les naviagteurs.
C'est vrai, mais c'est la seule que j'aie trouvé qui réponde sans ambi- guïté à des questions telles que « est-ce que le flag s est autorisé dans les RegExp » ?
[...] comme je ne me sent pas sûr en regexp je teste.
(¹) C.Q.F.D.
amha, on ne se réfère à la doc que quand il y a un pb, il faut se poser
des questions, avoir rencontré un problème, pour aller lire une doc,
plutôt mal faite en ce qui concerne le "web", bien souvent on (je)
fonctionne par analogie d'un langage à un autre.
Oui, je vois que nos deux approches de la programmation sont très
différentes. Personnellement je préfère lire la doc avant et avoir
un code qui marche du premier coup, plutôt que de passer du temps
après coup pour débuguer. Aussi, lorsque je dois débuguer le code
de quelqu'un d'autre, je le fais le plus possible en lisant le code
(donc sans l'exécuter) au lieu de procéder par essais et erreurs(¹).
[...]
soit dit en passant je doute que Ecma-262.pdf soit une docum faite pour
l'utilisateur de js, c'est plutôt une spec écrite pour ceux, sans doute
très peu nombreux, qui implémentent js dans les naviagteurs.
C'est vrai, mais c'est la seule que j'aie trouvé qui réponde sans ambi-
guïté à des questions telles que « est-ce que le flag s est autorisé
dans les RegExp » ?
[...] comme je ne me sent pas sûr en regexp je teste.
amha, on ne se réfère à la doc que quand il y a un pb, il faut se poser des questions, avoir rencontré un problème, pour aller lire une doc, plutôt mal faite en ce qui concerne le "web", bien souvent on (je) fonctionne par analogie d'un langage à un autre.
Oui, je vois que nos deux approches de la programmation sont très différentes. Personnellement je préfère lire la doc avant et avoir un code qui marche du premier coup, plutôt que de passer du temps après coup pour débuguer. Aussi, lorsque je dois débuguer le code de quelqu'un d'autre, je le fais le plus possible en lisant le code (donc sans l'exécuter) au lieu de procéder par essais et erreurs(¹).
[...]
soit dit en passant je doute que Ecma-262.pdf soit une docum faite pour l'utilisateur de js, c'est plutôt une spec écrite pour ceux, sans doute très peu nombreux, qui implémentent js dans les naviagteurs.
C'est vrai, mais c'est la seule que j'aie trouvé qui réponde sans ambi- guïté à des questions telles que « est-ce que le flag s est autorisé dans les RegExp » ?
[...] comme je ne me sent pas sûr en regexp je teste.
