Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Iterable Elements

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Iterable Elements
  • Date: Wed, 30 May 2007 06:18:19 -0400

Randall R Schulz wrote:
Elliotte,

On Tuesday 29 May 2007 18:17, Elliotte Harold wrote:
Cass Costello wrote:
What are the disadvantages you see, Elliotte?
Incompatibility with everyone still on 1.4 is the big problem.

Java 5 / 1.5 was released by Sun two years and eight months ago today. We're very far out from that release. Compatibility with 1.4 is a dinosaur problem, and it is highly dubious whether institutions that cannot find a way to migrate to 1.5 should dominate the decisions of library providers.

I'd estimate at least half of the market is still on 1.4, maybe more. No way I'm throwing that away.

If there were real benefits to moving to 1.5, I'd consider it a little more, but I don't see any compelling gains to be made here.

It would also needlessly duplicate functionality in the API. In XOM
there's exactly one way to do it, and Iterator isn't it. Use a
NodeList.

Finally, you'd have to figure out what to do about the remove()
operation. I don't think there's a good answer for that.

There's no obligation to implement remove(). You can throw an OperationNotSupportedException while remaining compliant with the API specification. See <http://java.sun.com/j2se/1.5.0/docs/api/> for confirmation.

UnsupportedOperationException is an ugly hack that should never have been allowed in the Collections API. It is a nasty wart on Java, and a one reason I don't want to expose the Collections API in my API at all.

Implementing remove is Scylla. Not implementing it is Charybdis. Neither option is acceptable. I choose for XOM to sail a different route completely.

XOM quite deliberately does not expose overly generic collections
APIs that don't perfectly fit the problem space. I don't intend to
start now.

Iteration over interior nodes does not "perfectly fit" an object model that is strictly tree structured? That's hard to accept or defend.


That's not the problem I alluded to. The real problem comes down to the return type of next() and unreified generics.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/




Archive powered by MHonArc 2.6.24.

Top of Page