Why doesn't NodeList extend Collection or Iterable?

Question

Perhaps this isn't exactly a programming question. But...

Why is org.w3c.dom.NodeList not an extension of java.lang.Iterable interface?

It sounds so counter-intuitive to me. Especially because the documentation says:

The NodeList interface provides the abstraction of an ordered collection of nodes, without defining or constraining how this collection is implemented. NodeList objects in the DOM are live. The items in the NodeList are accessible via an integral index, starting from 0.

PS: Please back your answers with proper citations where applicable.

Muffler

Because DOM is terrible. It predates Iterable by a lot, and my guess is it's just a completely straightforward "port" of the W3C specification with no regard to "Java-likeness", and nobody really cared about going back to figure out how to make the API nicer and not break compatibility. (See also: Calendar.) – Assign

@Assign That'd be terrible - if true! Do we have any evidence for this or are we just guessing this part? I couldn't find any documentation anywhere regarding this. – Muffler

You assume such evidence exists, but neither JDK nor Java was initially developed in the open. This isn't really the place to ask if you want to know why a small group of people, none of which are SO members, made a given call years and years ago, or why nobody decided otherwise in the intervening time. You could try looking at the JSR site to see if there were any specific XML-related proposals that might have rejection reasons: jcp.org/en/jsr/tech?listBy=1&listByType=tech. The closest I can find is the JDOM one that was withdrawn after ten years of nobody caring. – Assign

Or, to put it another way: if my guess is correct, which is that the reason is "nobody really cared enough to fix this", then it's in fact very unlikely there would be any evidence to support it. (I recognize this is not the same as saying "the lack of evidence proves my guess was correct".) – Assign

Answer 1

org.w3c.dom.NodeList predates Iterable, which was introduced in Java version 1.5.

Maybe it wasn't updated for compatibility reasons, but I have no references for this.

Latterll

Oh! That seems like the right answer. I just checked that NodeList indeed predates Java version 1.5 during which Iterable was introduced. – Muffler

Such a terrible mistake to not update the API though! I'm visualizing millions of developers cursing the incompatibility. – Muffler

I'm sure they curse it for other reasons, as well. It's a truly gruesome API, typical design-by-committee dog crap. – Latterll

Answer 2

The w3c only define specifications (XML, XSLT, DOM, etc...) and are not trying to align the API to any specific language or platform.

Its intended for developer of parsers as a guideline to produce a product compliant with existing code that uses these parsers.

When you build your application framework, it's best to wrap all API calls so you can control how the API is accessed in different language or on different platforms.

In Java, JavaScript, C# or whatever your using, create a class\object that wraps accessing the API calls. In JavaScript it will help when making code cross-browser compliant, if your publishing your solution for multiple platforms, you will only have to update your wrapper class.

Here is an example below, however, you can get as fancy as you want, define your own wrapper interface and base class with descendent classes overriding to provide specific implementations.

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;

Occupant