NodeListがCollectionまたはIterableを拡張しないのはなぜですか？

Question

これはまさにプログラミングに関する質問ではありません。しかし...

なぜorg.w3c.dom.NodeListはjava.lang.Iterableインターフェイスの拡張ではありませんか？

私にとっては直感的ではないようです。特に、ドキュメントには次のように書かれています。

NodeListインターフェイスは、このコレクションの実装方法を定義または制約することなく、ノードの順序付きコレクションの抽象化を提供します。 DOMのNodeListオブジェクトはライブです。 NodeListの中 のアイテムは0

PSから始まる整数のインデックスを使用してアクセスできます：該当する場合は、適切な引用とあなたの答えをバックアップしてください。

Answer 1

org.w3c.dom.NodeList pred Iterable Javaバージョン1.5で導入されました。

多分互換性の理由で更新されていないかもしれませんが、私はこれについての参照はありません。

Answer 2

w3cは仕様（XML、XSLT、DOMなど）を定義するだけで、APIを特定の言語やプラットフォームに合わせようとしていません。

これらのパーサーを使用する既存のコードに準拠する製品を作成するためのガイドラインとして、パーサーの開発者を対象としています。

アプリケーションフレームワークを構築する際には、すべてのAPI呼び出しをラップして、異なる言語または異なるプラットフォームでAPIへのアクセス方法を制御できるようにすることをお勧めします。

Java、JavaScript、C＃などで使用する場合は、API呼び出しにラップするクラス\オブジェクトを作成します。 JavaScriptでは、クロスブラウザ対応のコードを作成するときに役立ちます。複数のプラットフォーム用のソリューションを公開する場合は、ラッパークラスを更新するだけで済みます。

以下の例がありますが、あなたが望むように気に入ったようになり、固有の実装を提供するために独自のラッパーインターフェイスと子クラスをオーバーライドした基本クラスを定義できます。

function XMLNode(xnode) { 
    this.xnode = xnode; 
} 

function getNodes(path, xnode) { 
    if (browseTYPE != IE) { 

     //Ordered SnapShot 
     if (xnode.evaluate)   
      fld = xnode.evaluate(path, xnode, null, 7, null); 
     else 
      fld = xnode.ownerDocument.evaluate(path, xnode, null, 7, null); 

     //We need a result wrapper here 
     if (fld != null) return new XMLSnapShotList(fld); 

    } else { 
     fld = xnode.selectSingleNode(path).childNodes; 

     //We need a result wrapper here 
     if (fld != null) return new XMLList(fld); 
    } 
    return null; 
} 

XMLNode.prototype.getNodes = getNodes;