Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
supposons que j'ai deux objets "identiques", càd avec les mêmes couples de propriété/valeur :
var o1={element:one, type:'keyup',code:82,action:setToRed}; var o2={element:one, type:'keyup',code:82,action:setToRed};
"one" étant une référence à une DIV Element et "setToRed" une fonction.
si je fais alert(o1===o2) ça me dit false ??? pourquoi ???
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas pour des objets qui ne sont pas de type Undefined, Null, Number, String ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints » (au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de l'opérateur ===.
Voir les paragraphes que j'ai cités dans <http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>.
supposons que j'ai deux objets "identiques", càd avec les mêmes couples
de propriété/valeur :
var o1={element:one, type:'keyup',code:82,action:setToRed};
var o2={element:one, type:'keyup',code:82,action:setToRed};
"one" étant une référence à une DIV Element et "setToRed" une fonction.
si je fais alert(o1===o2) ça me dit false ???
pourquoi ???
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas
pour des objets qui ne sont pas de type Undefined, Null, Number, String
ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints »
(au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de
l'opérateur ===.
Voir les paragraphes que j'ai cités dans
<http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>.
supposons que j'ai deux objets "identiques", càd avec les mêmes couples de propriété/valeur :
var o1={element:one, type:'keyup',code:82,action:setToRed}; var o2={element:one, type:'keyup',code:82,action:setToRed};
"one" étant une référence à une DIV Element et "setToRed" une fonction.
si je fais alert(o1===o2) ça me dit false ??? pourquoi ???
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas pour des objets qui ne sont pas de type Undefined, Null, Number, String ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints » (au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de l'opérateur ===.
Voir les paragraphes que j'ai cités dans <http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>.
unbewusst.sein
Olivier Miakinen <om+ wrote:
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas pour des objets qui ne sont pas de type Undefined, Null, Number, String ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints » (au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de l'opérateur ===.
pourquoi "intérêt" de l'opérateur, perso ça m'a surpris, mais j'ai plutôt une formation en maths qu'en info, de là ma difficulté avec ces opérateurs j'ai tendance à les prendre comme identité...
et puis je ne trouve pas ça "intéressant", pour moi o1 ou o2 ne sont que des noms d'objets et je raisonne en contenu.
Voir les paragraphes que j'ai cités dans <http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>.
dommage qu'ils n'aient pas prévu un système de navigation dans ce document. (aussi la pagination est fausse)
je lis : 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas là...
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this, pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
-- Une Bévue
Olivier Miakinen <om+news@miakinen.net> wrote:
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas
pour des objets qui ne sont pas de type Undefined, Null, Number, String
ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints »
(au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de
l'opérateur ===.
pourquoi "intérêt" de l'opérateur, perso ça m'a surpris, mais j'ai
plutôt une formation en maths qu'en info, de là ma difficulté avec ces
opérateurs j'ai tendance à les prendre comme identité...
et puis je ne trouve pas ça "intéressant", pour moi o1 ou o2 ne sont que
des noms d'objets et je raisonne en contenu.
Voir les paragraphes que j'ai cités dans
<http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>.
dommage qu'ils n'aient pas prévu un système de navigation dans ce
document. (aussi la pagination est fausse)
je lis :
2. If Type(x) is Undefined, return true.
3. If Type(x) is Null, return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas
là...
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this,
pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas pour des objets qui ne sont pas de type Undefined, Null, Number, String ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints » (au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de l'opérateur ===.
pourquoi "intérêt" de l'opérateur, perso ça m'a surpris, mais j'ai plutôt une formation en maths qu'en info, de là ma difficulté avec ces opérateurs j'ai tendance à les prendre comme identité...
et puis je ne trouve pas ça "intéressant", pour moi o1 ou o2 ne sont que des noms d'objets et je raisonne en contenu.
Voir les paragraphes que j'ai cités dans <http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>.
dommage qu'ils n'aient pas prévu un système de navigation dans ce document. (aussi la pagination est fausse)
je lis : 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas là...
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this, pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
-- Une Bévue
Olivier Miakinen
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas pour des objets qui ne sont pas de type Undefined, Null, Number, String ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints » (au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de l'opérateur ===.
pourquoi "intérêt" de l'opérateur, perso ça m'a surpris, mais j'ai plutôt une formation en maths qu'en info, de là ma difficulté avec ces opérateurs j'ai tendance à les prendre comme identité...
L'intérêt d'avoir deux opérateurs, c'est justement de pouvoir faire la distinction entre l'égalité (==) et l'identité (===). Ici, tu as deux objets distincts (il n'y a donc pas identité : tu peux modifier l'un sans modifier l'autre) mais qui se trouvent avoir les mêmes valeurs (il y a donc égalité). Pourquoi ne pas utiliser plutôt l'opérateur == ?
dommage qu'ils n'aient pas prévu un système de navigation dans ce document. (aussi la pagination est fausse)
Si le c½ur t'en dit, n'hésite pas à fournir une version HTML de ce document PDF. Tu peux même le traduire en français, ce serait sympa. Merci !
(Et la pagination n'est pas fausse, mais c'est peut-être la première fois que tu vois la version électronique d'un document destiné à être imprimé.)
je lis : 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas là...
Qu'est-ce qui te surprend dans le fait que undefined === undefined et que null === null ?
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this, pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
Vu comment tu rajoutes des au petit bonheur la chance au lieu d'essayer de comprendre les choses, je dois dire que ça ne m'étonne pas que tu te fasses souvent surprendre... ;-)
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas
pour des objets qui ne sont pas de type Undefined, Null, Number, String
ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints »
(au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de
l'opérateur ===.
pourquoi "intérêt" de l'opérateur, perso ça m'a surpris, mais j'ai
plutôt une formation en maths qu'en info, de là ma difficulté avec ces
opérateurs j'ai tendance à les prendre comme identité...
L'intérêt d'avoir deux opérateurs, c'est justement de pouvoir faire la
distinction entre l'égalité (==) et l'identité (===). Ici, tu as deux
objets distincts (il n'y a donc pas identité : tu peux modifier l'un
sans modifier l'autre) mais qui se trouvent avoir les mêmes valeurs
(il y a donc égalité). Pourquoi ne pas utiliser plutôt l'opérateur == ?
dommage qu'ils n'aient pas prévu un système de navigation dans ce
document. (aussi la pagination est fausse)
Si le c½ur t'en dit, n'hésite pas à fournir une version HTML de ce
document PDF. Tu peux même le traduire en français, ce serait sympa.
Merci !
(Et la pagination n'est pas fausse, mais c'est peut-être la première
fois que tu vois la version électronique d'un document destiné à être
imprimé.)
je lis :
2. If Type(x) is Undefined, return true.
3. If Type(x) is Null, return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas
là...
Qu'est-ce qui te surprend dans le fait que undefined === undefined et
que null === null ?
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this,
pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
Vu comment tu rajoutes des au petit bonheur la chance au lieu
d'essayer de comprendre les choses, je dois dire que ça ne m'étonne
pas que tu te fasses souvent surprendre... ;-)
Parce que le paragraphe 11.9.6 de la norme dit que ça doit être le cas pour des objets qui ne sont pas de type Undefined, Null, Number, String ou Boolean, et qui ne sont ni « le même objet » ni « des objets joints » (au sens du paragraphe 13.1.2). C'est d'ailleurs le principal intérêt de l'opérateur ===.
pourquoi "intérêt" de l'opérateur, perso ça m'a surpris, mais j'ai plutôt une formation en maths qu'en info, de là ma difficulté avec ces opérateurs j'ai tendance à les prendre comme identité...
L'intérêt d'avoir deux opérateurs, c'est justement de pouvoir faire la distinction entre l'égalité (==) et l'identité (===). Ici, tu as deux objets distincts (il n'y a donc pas identité : tu peux modifier l'un sans modifier l'autre) mais qui se trouvent avoir les mêmes valeurs (il y a donc égalité). Pourquoi ne pas utiliser plutôt l'opérateur == ?
dommage qu'ils n'aient pas prévu un système de navigation dans ce document. (aussi la pagination est fausse)
Si le c½ur t'en dit, n'hésite pas à fournir une version HTML de ce document PDF. Tu peux même le traduire en français, ce serait sympa. Merci !
(Et la pagination n'est pas fausse, mais c'est peut-être la première fois que tu vois la version électronique d'un document destiné à être imprimé.)
je lis : 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas là...
Qu'est-ce qui te surprend dans le fait que undefined === undefined et que null === null ?
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this, pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
Vu comment tu rajoutes des au petit bonheur la chance au lieu d'essayer de comprendre les choses, je dois dire que ça ne m'étonne pas que tu te fasses souvent surprendre... ;-)
unbewusst.sein
Olivier Miakinen <om+ wrote:
L'intérêt d'avoir deux opérateurs, c'est justement de pouvoir faire la distinction entre l'égalité (==) et l'identité (===). Ici, tu as deux objets distincts (il n'y a donc pas identité : tu peux modifier l'un sans modifier l'autre) mais qui se trouvent avoir les mêmes valeurs (il y a donc égalité). Pourquoi ne pas utiliser plutôt l'opérateur == ?
dommage qu'ils n'aient pas prévu un système de navigation dans ce document. (aussi la pagination est fausse)
Si le c½ur t'en dit, n'hésite pas à fournir une version HTML de ce document PDF. Tu peux même le traduire en français, ce serait sympa. Merci !
en sortir une version html oui, mais traduire non. je regarderai s'il y a des outils de conversion pdf vers html, ce que je n'ai jamais fait. c'est vrai qu'il serait bien d'avoir ça comme "panel" de ff ou opera par ex (<http://people.opera.com/rijk/panels/panelizer.html>).
(Et la pagination n'est pas fausse, mais c'est peut-être la première fois que tu vois la version électronique d'un document destiné à être imprimé.)
ben je n'imprime jamais ce genre de document.
je lis : 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas là...
Qu'est-ce qui te surprend dans le fait que undefined === undefined et que null === null ?
autant pour moi après "1. If Type(x) is different from Type(y), return false."
les deux objets sont nécessairement de même "type".
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this, pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
Vu comment tu rajoutes des au petit bonheur la chance au lieu d'essayer de comprendre les choses, je dois dire que ça ne m'étonne pas que tu te fasses souvent surprendre... ;-)
ben désolé pour moi { est un métacaractère, de ce que je me souviens (d'autres langages que js il est vrai) il faut escaper (???);
j'échappe "{" comme j'échappe ".".
je lis p 142 du pdf ecma : PatternCharacter :: SourceCharacter but not any of: ^ $ . * + ? ( ) [ ] { } |
-- Une Bévue
Olivier Miakinen <om+news@miakinen.net> wrote:
L'intérêt d'avoir deux opérateurs, c'est justement de pouvoir faire la
distinction entre l'égalité (==) et l'identité (===). Ici, tu as deux
objets distincts (il n'y a donc pas identité : tu peux modifier l'un sans
modifier l'autre) mais qui se trouvent avoir les mêmes valeurs (il y a
donc égalité). Pourquoi ne pas utiliser plutôt l'opérateur == ?
dommage qu'ils n'aient pas prévu un système de navigation dans ce
document. (aussi la pagination est fausse)
Si le c½ur t'en dit, n'hésite pas à fournir une version HTML de ce
document PDF. Tu peux même le traduire en français, ce serait sympa. Merci
!
en sortir une version html oui, mais traduire non. je regarderai s'il y
a des outils de conversion pdf vers html, ce que je n'ai jamais fait.
c'est vrai qu'il serait bien d'avoir ça comme "panel" de ff ou opera par
ex (<http://people.opera.com/rijk/panels/panelizer.html>).
(Et la pagination n'est pas fausse, mais c'est peut-être la première fois
que tu vois la version électronique d'un document destiné à être
imprimé.)
ben je n'imprime jamais ce genre de document.
je lis : 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null,
return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas
là...
Qu'est-ce qui te surprend dans le fait que undefined === undefined et que
null === null ?
autant pour moi après "1. If Type(x) is different from Type(y), return
false."
les deux objets sont nécessairement de même "type".
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this,
pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
Vu comment tu rajoutes des au petit bonheur la chance au lieu d'essayer
de comprendre les choses, je dois dire que ça ne m'étonne pas que tu te
fasses souvent surprendre... ;-)
ben désolé pour moi { est un métacaractère, de ce que je me souviens
(d'autres langages que js il est vrai) il faut escaper (???);
j'échappe "{" comme j'échappe ".".
je lis p 142 du pdf ecma : PatternCharacter :: SourceCharacter but not
any of: ^ $ . * + ? ( ) [ ] { } |
L'intérêt d'avoir deux opérateurs, c'est justement de pouvoir faire la distinction entre l'égalité (==) et l'identité (===). Ici, tu as deux objets distincts (il n'y a donc pas identité : tu peux modifier l'un sans modifier l'autre) mais qui se trouvent avoir les mêmes valeurs (il y a donc égalité). Pourquoi ne pas utiliser plutôt l'opérateur == ?
dommage qu'ils n'aient pas prévu un système de navigation dans ce document. (aussi la pagination est fausse)
Si le c½ur t'en dit, n'hésite pas à fournir une version HTML de ce document PDF. Tu peux même le traduire en français, ce serait sympa. Merci !
en sortir une version html oui, mais traduire non. je regarderai s'il y a des outils de conversion pdf vers html, ce que je n'ai jamais fait. c'est vrai qu'il serait bien d'avoir ça comme "panel" de ff ou opera par ex (<http://people.opera.com/rijk/panels/panelizer.html>).
(Et la pagination n'est pas fausse, mais c'est peut-être la première fois que tu vois la version électronique d'un document destiné à être imprimé.)
ben je n'imprime jamais ce genre de document.
je lis : 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true.
très surprenant, heureusement dans ma comparaison j'ai supprimé ces cas là...
Qu'est-ce qui te surprend dans le fait que undefined === undefined et que null === null ?
autant pour moi après "1. If Type(x) is different from Type(y), return false."
les deux objets sont nécessairement de même "type".
de même je ne comprend pas le test : if(p)
enfin, ce que je veux dire, je ne comprend pas le choix qui a été fait
je me suis fait avoir récemment avec un "if(this[p])"
où je voulais tester l'existence de la propriété p pour l'objet this, pas de pot je suis tombé sur un cas où this[p]=0;
et donc ça m'a retourné faux quand j'escomptais true ;-)
Vu comment tu rajoutes des au petit bonheur la chance au lieu d'essayer de comprendre les choses, je dois dire que ça ne m'étonne pas que tu te fasses souvent surprendre... ;-)
ben désolé pour moi { est un métacaractère, de ce que je me souviens (d'autres langages que js il est vrai) il faut escaper (???);
j'échappe "{" comme j'échappe ".".
je lis p 142 du pdf ecma : PatternCharacter :: SourceCharacter but not any of: ^ $ . * + ? ( ) [ ] { } |
-- Une Bévue
unbewusst.sein
Olivier Miakinen <om+ wrote:
Si le c½ur t'en dit, n'hésite pas à fournir une version HTML de ce document PDF.
la "rectee" donnée à la page : <http://labnol.blogspot.com/2005/12/convert-doc-xls-ppt-rtf-pdf-to-html. html>
ne fonctionne pas pour ce document jugé trop volumineux, j'ai essayé, ça s'arrête à la page 118, non totalement incluse. -- Une Bévue
Olivier Miakinen <om+news@miakinen.net> wrote:
Si le c½ur t'en dit, n'hésite pas à fournir une version HTML de ce
document PDF.
la "rectee" donnée à la page :
<http://labnol.blogspot.com/2005/12/convert-doc-xls-ppt-rtf-pdf-to-html.
html>
ne fonctionne pas pour ce document jugé trop volumineux, j'ai essayé, ça
s'arrête à la page 118, non totalement incluse.
--
Une Bévue
