pourquoi NodeList n'est pas une Array ?

Le
unbewusst.sein
Je me demande pourquoi pourquoi NodeList n'est pas une Array ?

c'est tellement plus facile en Array que j'ai implémenté une méthode
#toArray() sur NodeList :
NodeList.prototype.toArray=function(){
var a=[];
for(var i=0, l=this.length;i<l;i++){
a.push(this[i]);
}
return a;
}


--
« L'humanité qui devrait avoir six mille ans d'expérience,
retombe en enfance à chaque génération. »
(Tristan Bernard)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mickaël Wolff
Le #23884561
On 19/10/11 04:07, Une Bévue wrote:
Je me demande pourquoi pourquoi NodeList n'est pas une Array ?



Array est un type Ecmascript/Javascript. NodeList est un type
générique défini par DOM. DOM a été pensé pour ne pas dépendre du
langage dans lequel il est implémenté.

c'est tellement plus facile en Array que j'ai implémenté une méthode
#toArray() sur NodeList :
NodeList.prototype.toArray=function(){
var a=[];
for(var i=0, l=this.length;i<l;i++){
a.push(this[i]);
}
return a;
}



En quoi est-ce plus facile ?
unbewusst.sein
Le #23884921
Mickaël Wolff
On 19/10/11 04:07, Une Bévue wrote:
> Je me demande pourquoi pourquoi NodeList n'est pas une Array ?

Array est un type Ecmascript/Javascript. NodeList est un type
générique défini par DOM. DOM a été pensé pour ne pas dépendre du
langage dans lequel il est implémenté.



Ben c'est "pensé" de travers alors...
De toutes façons le DOM dans un browser n'est accessible que par js non
?
Aujourd'hui, il n'y a pas d'autres langages pour butineur ?

Je mets à part les tentatives CoffeeScript et Dart qui de toutes façons
"compilent" en js.

> c'est tellement plus facile en Array que j'ai implémenté une méthode


<snip />


En quoi est-ce plus facile ?



ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des
éléments.

--
« Si tous ceux qui n'ont rien n'en demandaient pas plus,
il serait bien facile de contenter tout le monde. »
(Coluche)
Mickaël Wolff
Le #23892011
On 20/10/11 07:16, Une Bévue wrote:

Ben c'est "pensé" de travers alors...


Ben non, c'est pensé de manière orthogonale :D

De toutes façons le DOM dans un browser n'est accessible que par js non
?


Non, depuis ActiveScript, depuis ActiveX, etc.

Aujourd'hui, il n'y a pas d'autres langages pour butineur ?


DOM est une spécification indépendante du langage et de
l'environnement d'exécution. DOM ne sert pas que dans un navigateur. La
libxml du projet GNOME implémente une version écrite en C de DOM. PHP
fournit aussi une implémentation de DOM, et Python, etc.

Je sais que trop souvent, on considère /a priori/, JavaScript et DOM
comme des technologies uniquement disponibles dans un navigateur Web. En
réalité, ce sont des technologies qui n'y sont pas spécifiques.

ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des
éléments.



Ceci peut poser problème. Un NodeList n'est pas un tableau, mais une
liste chainée. Chaque élément connait ses voisins, son parent et ses
enfants. C'est cette structure qui est considérée dans DOM, c'est à
cette structure que l'API DOM donne accès. C'est pour ça que les
opérations d'insertion, de suppression ou de remplacement ne sont pas
triviale : on manipule un arbre DOM.

// Le parent est nécessaire pour supprimer un nœud
nodeToBeRemoved.parent.removeChild(nodeToBeRemoved);

// Pour remplacer un nœud, il faut connaître le parent
// et surtout, le nœud à insérer doit être connu du document
// propriétaire dans lequel il est inséré
nodeToBeReplaced.parent
.replaceChild(replacementNode, nodeToBeReplaced);

J'espère que tu comprends mieux le pourquoi des choix de conception
de DOM. Ce n'est pas parce qu'ils ne correspondent pas à ton besoin
immédiat qu'ils sont abérants ;)
Une Bévue
Le #23892441
Le 22/10/2011 04:40, Mickaël Wolff a écrit :
On 20/10/11 07:16, Une Bévue wrote:

Ben c'est "pensé" de travers alors...


Ben non, c'est pensé de manière orthogonale :D

De toutes façons le DOM dans un browser n'est accessible que par js non
?


Non, depuis ActiveScript, depuis ActiveX, etc.

Aujourd'hui, il n'y a pas d'autres langages pour butineur ?


DOM est une spécification indépendante du langage et de l'environnement
d'exécution. DOM ne sert pas que dans un navigateur. La libxml du projet
GNOME implémente une version écrite en C de DOM. PHP fournit aussi une
implémentation de DOM, et Python, etc.

Je sais que trop souvent, on considère /a priori/, JavaScript et DOM
comme des technologies uniquement disponibles dans un navigateur Web. En
réalité, ce sont des technologies qui n'y sont pas spécifiques.

ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des
éléments.



Ceci peut poser problème. Un NodeList n'est pas un tableau, mais une
liste chainée. Chaque élément connait ses voisins, son parent et ses
enfants. C'est cette structure qui est considérée dans DOM, c'est à
cette structure que l'API DOM donne accès. C'est pour ça que les
opérations d'insertion, de suppression ou de remplacement ne sont pas
triviale : on manipule un arbre DOM.

// Le parent est nécessaire pour supprimer un nœud
nodeToBeRemoved.parent.removeChild(nodeToBeRemoved);

// Pour remplacer un nœud, il faut connaître le parent
// et surtout, le nœud à insérer doit être connu du document
// propriétaire dans lequel il est inséré
nodeToBeReplaced.parent
.replaceChild(replacementNode, nodeToBeReplaced);

J'espère que tu comprends mieux le pourquoi des choix de conception de
DOM. Ce n'est pas parce qu'ils ne correspondent pas à ton besoin
immédiat qu'ils sont abérants ;)



ouais, OK, c'est retenu !
Publicité
Poster une réponse
Anonyme