Oui, peu importe le type des éléments puisque ce qui m'intéressai t ici
c'étaient les index. Je voulais montrer qu'un tableau en JavaScript
n'est qu'un objet comme un autre, avec une liste de propriétés, aus si
bien pour un tableau associatif que pour un tableau (que l'on croit)
indexé par des entiers.
Oui, peu importe le type des éléments puisque ce qui m'intéressai t ici
c'étaient les index. Je voulais montrer qu'un tableau en JavaScript
n'est qu'un objet comme un autre, avec une liste de propriétés, aus si
bien pour un tableau associatif que pour un tableau (que l'on croit)
indexé par des entiers.
Oui, peu importe le type des éléments puisque ce qui m'intéressai t ici
c'étaient les index. Je voulais montrer qu'un tableau en JavaScript
n'est qu'un objet comme un autre, avec une liste de propriétés, aus si
bien pour un tableau associatif que pour un tableau (que l'on croit)
indexé par des entiers.
Le 26/03/2010 11:13, Bol a écrit :Exemple rapide, Firefox, console, code :
Où trouves-tu ça dans Firefox ? C'est une extension ?
donne
1000,
Oui.
Le 26/03/2010 11:13, Bol a écrit :
Exemple rapide, Firefox, console, code :
Où trouves-tu ça dans Firefox ? C'est une extension ?
donne
1000,
Oui.
Le 26/03/2010 11:13, Bol a écrit :Exemple rapide, Firefox, console, code :
Où trouves-tu ça dans Firefox ? C'est une extension ?
donne
1000,
Oui.
Oui, peu importe le type des éléments puisque ce qui m'intéressait ici
c'étaient les index. Je voulais montrer qu'un tableau en JavaScript
n'est qu'un objet comme un autre, avec une liste de propriétés, aussi
bien pour un tableau associatif que pour un tableau (que l'on croit)
indexé par des entiers.
Désolé, mais ça ne me parait pas si simple.
Si les deux types de tableaux étaient traités de manière identique, on
aurait le comportement suivant :
1. La propriété "length" serait disponible dans les deux cas.
2. Ajouter une propriété à un tableau indexé augmenterait sa taille,
même si la propriété en question n'est pas un indice entier.
3. Mélanger des clés indicées et littérales pour un même tableau
obligerait, soit à considérer un type mixte (comme en PHP), soit à
fusionner l'ensemble dans le type associatif.
Or, ce n'est pas le cas.
Déjà, les deux types ne se créent pas de la même manière, on est bien
d'accord. Soit, littéralement, [val1, val2, ..., valN] pour l'indexé et
{prop1: val1, prop2: val2, ..., propN: valN} pour l'associatif.
Certes, JS renverra pour les deux tableaux une valeur "object" avec
l'instruction "typeof". Mais c'est aussi vrai pour une chaîne ou un
nombre s'ils sont créés avec les constructeurs "String" et "Number".
Je me suis pris la tête avec Douglas Crockford à ce sujet, et David
Flanagan l'a bien confirmé : JS offre des objets englobants, qui peuvent
même être temporaires, et qu'il faut distinguer des types primitifs.
C'est d'ailleurs pour cette raison que Douglas recommande de ne pas
utiliser les constructeurs natifs pour initialiser les variables.
Donc, pour en revenir à nos tableaux, le fait d'ajouter une propriété à
un tableau indexé ne le "transforme" pas en tableau associatif, sinon il
perdrait la propriété "length" qui est héritée de son type primitif.
D'ailleurs, à propos de cette propriété, on peut noter qu'elle n'est pas
énumérée dans la boucle "for ... in" appliquée à un tableau indexé,
contrairement aux propriétés ajoutées dans le script.
Mais, pour ma part, je ne tenterais pas d'ajouter une "propriété" - au
sens de membre d'un objet - à un tableau indexé, même si JS le permet.
Car je crois que le type associatif, qui est le type objet primitif de
JS, me parait plus adapté pour cela, non ? Et puis quelle en serait la
véritable utilité ?
[...]
PS: je suis ouvert à continuer cette discussion hors forum pour ne pas
trop polluer [...]
Oui, peu importe le type des éléments puisque ce qui m'intéressait ici
c'étaient les index. Je voulais montrer qu'un tableau en JavaScript
n'est qu'un objet comme un autre, avec une liste de propriétés, aussi
bien pour un tableau associatif que pour un tableau (que l'on croit)
indexé par des entiers.
Désolé, mais ça ne me parait pas si simple.
Si les deux types de tableaux étaient traités de manière identique, on
aurait le comportement suivant :
1. La propriété "length" serait disponible dans les deux cas.
2. Ajouter une propriété à un tableau indexé augmenterait sa taille,
même si la propriété en question n'est pas un indice entier.
3. Mélanger des clés indicées et littérales pour un même tableau
obligerait, soit à considérer un type mixte (comme en PHP), soit à
fusionner l'ensemble dans le type associatif.
Or, ce n'est pas le cas.
Déjà, les deux types ne se créent pas de la même manière, on est bien
d'accord. Soit, littéralement, [val1, val2, ..., valN] pour l'indexé et
{prop1: val1, prop2: val2, ..., propN: valN} pour l'associatif.
Certes, JS renverra pour les deux tableaux une valeur "object" avec
l'instruction "typeof". Mais c'est aussi vrai pour une chaîne ou un
nombre s'ils sont créés avec les constructeurs "String" et "Number".
Je me suis pris la tête avec Douglas Crockford à ce sujet, et David
Flanagan l'a bien confirmé : JS offre des objets englobants, qui peuvent
même être temporaires, et qu'il faut distinguer des types primitifs.
C'est d'ailleurs pour cette raison que Douglas recommande de ne pas
utiliser les constructeurs natifs pour initialiser les variables.
Donc, pour en revenir à nos tableaux, le fait d'ajouter une propriété à
un tableau indexé ne le "transforme" pas en tableau associatif, sinon il
perdrait la propriété "length" qui est héritée de son type primitif.
D'ailleurs, à propos de cette propriété, on peut noter qu'elle n'est pas
énumérée dans la boucle "for ... in" appliquée à un tableau indexé,
contrairement aux propriétés ajoutées dans le script.
Mais, pour ma part, je ne tenterais pas d'ajouter une "propriété" - au
sens de membre d'un objet - à un tableau indexé, même si JS le permet.
Car je crois que le type associatif, qui est le type objet primitif de
JS, me parait plus adapté pour cela, non ? Et puis quelle en serait la
véritable utilité ?
[...]
PS: je suis ouvert à continuer cette discussion hors forum pour ne pas
trop polluer [...]
Oui, peu importe le type des éléments puisque ce qui m'intéressait ici
c'étaient les index. Je voulais montrer qu'un tableau en JavaScript
n'est qu'un objet comme un autre, avec une liste de propriétés, aussi
bien pour un tableau associatif que pour un tableau (que l'on croit)
indexé par des entiers.
Désolé, mais ça ne me parait pas si simple.
Si les deux types de tableaux étaient traités de manière identique, on
aurait le comportement suivant :
1. La propriété "length" serait disponible dans les deux cas.
2. Ajouter une propriété à un tableau indexé augmenterait sa taille,
même si la propriété en question n'est pas un indice entier.
3. Mélanger des clés indicées et littérales pour un même tableau
obligerait, soit à considérer un type mixte (comme en PHP), soit à
fusionner l'ensemble dans le type associatif.
Or, ce n'est pas le cas.
Déjà, les deux types ne se créent pas de la même manière, on est bien
d'accord. Soit, littéralement, [val1, val2, ..., valN] pour l'indexé et
{prop1: val1, prop2: val2, ..., propN: valN} pour l'associatif.
Certes, JS renverra pour les deux tableaux une valeur "object" avec
l'instruction "typeof". Mais c'est aussi vrai pour une chaîne ou un
nombre s'ils sont créés avec les constructeurs "String" et "Number".
Je me suis pris la tête avec Douglas Crockford à ce sujet, et David
Flanagan l'a bien confirmé : JS offre des objets englobants, qui peuvent
même être temporaires, et qu'il faut distinguer des types primitifs.
C'est d'ailleurs pour cette raison que Douglas recommande de ne pas
utiliser les constructeurs natifs pour initialiser les variables.
Donc, pour en revenir à nos tableaux, le fait d'ajouter une propriété à
un tableau indexé ne le "transforme" pas en tableau associatif, sinon il
perdrait la propriété "length" qui est héritée de son type primitif.
D'ailleurs, à propos de cette propriété, on peut noter qu'elle n'est pas
énumérée dans la boucle "for ... in" appliquée à un tableau indexé,
contrairement aux propriétés ajoutées dans le script.
Mais, pour ma part, je ne tenterais pas d'ajouter une "propriété" - au
sens de membre d'un objet - à un tableau indexé, même si JS le permet.
Car je crois que le type associatif, qui est le type objet primitif de
JS, me parait plus adapté pour cela, non ? Et puis quelle en serait la
véritable utilité ?
[...]
PS: je suis ouvert à continuer cette discussion hors forum pour ne pas
trop polluer [...]
Je me complète : je voulais surtout montrer qu'un tableau avec deux
éléments indicés 1000 et 2000 ne prendra pas mille fois plus de p lace
qu'un tableau avec deux éléments indicés 1 et 2.
Note que je n'ai pas dit que le traitement était identique, juste que le
type de stockage était le même. On voit bien que pour un tableau so nt
traités de façon très particulière d'une part les indices entie rs entre
0 et 2^32-1, d'autre part la valeur length.
2. Ajouter une propriété à un tableau indexé augmenterait sa t aille,
même si la propriété en question n'est pas un indice entier.
Tu parles de la taille en mémoire, ou de la valeur de la propriété
length ?
Ce sont deux notions assez indépendantes l'une de l'autre.
[...] En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C' est donc
un type associatif, mais où un traitement particulier est fait lorsqu e
l'« indice » représente un entier entre 0 et 2^32-1.
Je me suis pris la tête avec Douglas Crockford à ce sujet, [...]
Euh... je n'ai pas tout suivi, là.
[...] Je suppose que c'est parce que cette propriété est dans le
prototype de l'objet plutôt que copiée dans l'objet lui-même ? [. ..]
Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)
Je me complète : je voulais surtout montrer qu'un tableau avec deux
éléments indicés 1000 et 2000 ne prendra pas mille fois plus de p lace
qu'un tableau avec deux éléments indicés 1 et 2.
Note que je n'ai pas dit que le traitement était identique, juste que le
type de stockage était le même. On voit bien que pour un tableau so nt
traités de façon très particulière d'une part les indices entie rs entre
0 et 2^32-1, d'autre part la valeur length.
2. Ajouter une propriété à un tableau indexé augmenterait sa t aille,
même si la propriété en question n'est pas un indice entier.
Tu parles de la taille en mémoire, ou de la valeur de la propriété
length ?
Ce sont deux notions assez indépendantes l'une de l'autre.
[...] En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C' est donc
un type associatif, mais où un traitement particulier est fait lorsqu e
l'« indice » représente un entier entre 0 et 2^32-1.
Je me suis pris la tête avec Douglas Crockford à ce sujet, [...]
Euh... je n'ai pas tout suivi, là.
[...] Je suppose que c'est parce que cette propriété est dans le
prototype de l'objet plutôt que copiée dans l'objet lui-même ? [. ..]
Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)
Je me complète : je voulais surtout montrer qu'un tableau avec deux
éléments indicés 1000 et 2000 ne prendra pas mille fois plus de p lace
qu'un tableau avec deux éléments indicés 1 et 2.
Note que je n'ai pas dit que le traitement était identique, juste que le
type de stockage était le même. On voit bien que pour un tableau so nt
traités de façon très particulière d'une part les indices entie rs entre
0 et 2^32-1, d'autre part la valeur length.
2. Ajouter une propriété à un tableau indexé augmenterait sa t aille,
même si la propriété en question n'est pas un indice entier.
Tu parles de la taille en mémoire, ou de la valeur de la propriété
length ?
Ce sont deux notions assez indépendantes l'une de l'autre.
[...] En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C' est donc
un type associatif, mais où un traitement particulier est fait lorsqu e
l'« indice » représente un entier entre 0 et 2^32-1.
Je me suis pris la tête avec Douglas Crockford à ce sujet, [...]
Euh... je n'ai pas tout suivi, là.
[...] Je suppose que c'est parce que cette propriété est dans le
prototype de l'objet plutôt que copiée dans l'objet lui-même ? [. ..]
Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)
[...]
Là je faisais référence à la propriété "length".
[...] Mais tu seras sans doute d'accord pour admettre qu'un
usage normalisé du type indexé ne fera pas apparaître de différence.
Par "normalisé", j'entends une indexation qui commence à zéro et sans
trous, et aucune propriété ajoutée par le script.
[...] En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C'est donc
un type associatif, mais où un traitement particulier est fait lorsque
l'« indice » représente un entier entre 0 et 2^32-1.
Pour moi, c'est là où ça ne colle pas.
Je pense au contraire qu'un tableau indexé sous JS stocke les indices
sous formes entière, alors qu'un tableau associatif stocke les clés sous
formes de chaînes pointant vers les propriétés correspondantes (càd une
zone mémoire où sont stockées leurs valeurs respectives).
15.4.5.1 [[Put]] (P, V)
Array objects use a variation of the [[Put]] method used for other native ECMAScript objects
(8.6.2.2).
Assume A is an Array object and P is a string.
When the [[Put]] method of A is called with property P and value V, the following steps are taken:
1. Call the [[CanPut]] method of A with name P.
2. If Result(1) is false, return.
3. If A doesn’t have a property with name P, go to step 7.
4. If P is "length", go to step 12.
5. Set the value of property P of A to V.
6. Go to step 8.
7. Create a property with name P, set its value to V and give it empty attributes.
8. If P is not an array index, return.
9. If ToUint32(P) is less than the value of the length property of A, then return.
10. Change (or set) the value of the length property of A to ToUint32(P)+1.
11. Return.
12. Compute ToUint32(V).
13. If Result(12) is not equal to ToNumber(V), throw a RangeError exception.
14. For every integer k that is less than the value of the length property of A but not less than
Result(12), if A itself has a property (not an inherited property) named ToString(k), then delete
that property.
15. Set the value of property P of A to Result(12).
16. Return.
[...]Je me suis pris la tête avec Douglas Crockford à ce sujet, [...]
Tu comprends maintenant pourquoi, hein ? ;-)
Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)
Non, bien sûr, mais on s'éloignait pas mal du fil de départ, alors je me
suis senti tout plein de scrupules ! ;-)
[...]
Là je faisais référence à la propriété "length".
[...] Mais tu seras sans doute d'accord pour admettre qu'un
usage normalisé du type indexé ne fera pas apparaître de différence.
Par "normalisé", j'entends une indexation qui commence à zéro et sans
trous, et aucune propriété ajoutée par le script.
[...] En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C'est donc
un type associatif, mais où un traitement particulier est fait lorsque
l'« indice » représente un entier entre 0 et 2^32-1.
Pour moi, c'est là où ça ne colle pas.
Je pense au contraire qu'un tableau indexé sous JS stocke les indices
sous formes entière, alors qu'un tableau associatif stocke les clés sous
formes de chaînes pointant vers les propriétés correspondantes (càd une
zone mémoire où sont stockées leurs valeurs respectives).
15.4.5.1 [[Put]] (P, V)
Array objects use a variation of the [[Put]] method used for other native ECMAScript objects
(8.6.2.2).
Assume A is an Array object and P is a string.
When the [[Put]] method of A is called with property P and value V, the following steps are taken:
1. Call the [[CanPut]] method of A with name P.
2. If Result(1) is false, return.
3. If A doesn’t have a property with name P, go to step 7.
4. If P is "length", go to step 12.
5. Set the value of property P of A to V.
6. Go to step 8.
7. Create a property with name P, set its value to V and give it empty attributes.
8. If P is not an array index, return.
9. If ToUint32(P) is less than the value of the length property of A, then return.
10. Change (or set) the value of the length property of A to ToUint32(P)+1.
11. Return.
12. Compute ToUint32(V).
13. If Result(12) is not equal to ToNumber(V), throw a RangeError exception.
14. For every integer k that is less than the value of the length property of A but not less than
Result(12), if A itself has a property (not an inherited property) named ToString(k), then delete
that property.
15. Set the value of property P of A to Result(12).
16. Return.
[...]
Je me suis pris la tête avec Douglas Crockford à ce sujet, [...]
Tu comprends maintenant pourquoi, hein ? ;-)
Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)
Non, bien sûr, mais on s'éloignait pas mal du fil de départ, alors je me
suis senti tout plein de scrupules ! ;-)
[...]
Là je faisais référence à la propriété "length".
[...] Mais tu seras sans doute d'accord pour admettre qu'un
usage normalisé du type indexé ne fera pas apparaître de différence.
Par "normalisé", j'entends une indexation qui commence à zéro et sans
trous, et aucune propriété ajoutée par le script.
[...] En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C'est donc
un type associatif, mais où un traitement particulier est fait lorsque
l'« indice » représente un entier entre 0 et 2^32-1.
Pour moi, c'est là où ça ne colle pas.
Je pense au contraire qu'un tableau indexé sous JS stocke les indices
sous formes entière, alors qu'un tableau associatif stocke les clés sous
formes de chaînes pointant vers les propriétés correspondantes (càd une
zone mémoire où sont stockées leurs valeurs respectives).
15.4.5.1 [[Put]] (P, V)
Array objects use a variation of the [[Put]] method used for other native ECMAScript objects
(8.6.2.2).
Assume A is an Array object and P is a string.
When the [[Put]] method of A is called with property P and value V, the following steps are taken:
1. Call the [[CanPut]] method of A with name P.
2. If Result(1) is false, return.
3. If A doesn’t have a property with name P, go to step 7.
4. If P is "length", go to step 12.
5. Set the value of property P of A to V.
6. Go to step 8.
7. Create a property with name P, set its value to V and give it empty attributes.
8. If P is not an array index, return.
9. If ToUint32(P) is less than the value of the length property of A, then return.
10. Change (or set) the value of the length property of A to ToUint32(P)+1.
11. Return.
12. Compute ToUint32(V).
13. If Result(12) is not equal to ToNumber(V), throw a RangeError exception.
14. For every integer k that is less than the value of the length property of A but not less than
Result(12), if A itself has a property (not an inherited property) named ToString(k), then delete
that property.
15. Set the value of property P of A to Result(12).
16. Return.
[...]Je me suis pris la tête avec Douglas Crockford à ce sujet, [...]
Tu comprends maintenant pourquoi, hein ? ;-)
Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)
Non, bien sûr, mais on s'éloignait pas mal du fil de départ, alors je me
suis senti tout plein de scrupules ! ;-)