Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Question on Elements and Nodes (and Attributes)

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Mik Lernout <mik AT futurestreet.org>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>, xom-interest AT lists.ibiblio.org
  • Cc:
  • Subject: Re: [XOM-interest] Question on Elements and Nodes (and Attributes)
  • Date: Tue, 27 Jan 2004 10:12:18 +0100

Well, I at least tried: I follow your reasoning for the Collections and when I slept over it I realized the .iterator() - solution is worse than doing nothing at all... I don't like Collections as well, but negating it completely seems a little drastic and unnecessary... It would already be cool to have easy access to a copy of the array of Elements like in the Collections 'toArray()' , you could make it type safe and it would be easy to use in a scripting language...

As for the Attributes: read your reply, watched tv, stared at the ceiling and am now fully complying to the standards :-)

PS: And also: when somebody is iterating and an element is removed, it will throw a ConcurrentModificationException, as it should...

Elliotte Rusty Harold wrote:

Hmm, allow me to disagree :-)

I like the type safety of the Nodes and Elements (really enjoyed your interview on Artima describing that by the way) but why could they not be implemented at the same time, for example by adding an iterator() on the Elements and the Nodes-classes, like in the attachment I send with this mail. It would not alter the type safetyness and, at the same time, allow access to the list in a Collections - standard way.


Because the Collections API is ugly as sin, in large part because it does not expose the types of the individual elements; blame the lack of generics for that. Plus it's confusing as hell. What happens when someone's iterating and an element is removed? Adding collections would provide no significant gain, and would make the API considerably more complex.

As for the Attributes argument: why is there getAttributeCount() and a getAttribute(int index) if you would only get them by name?


Sometimes you need that. It's just relatively rare.

I don't see the difference between Elements and Attributes: probably most people will use the getChildElements(name) and getAttribute(name), but we still need to provide access to the list of these items, in a clean way. If you would expose the Attributes you would bring down the number of methods on Element, standardize to calling a 'count' a 'size' everywhere and allow for another type safe "value-ish" object to interface with.



Elements and attributes are quite different. They are not equivalent. Most significantly, there cannot be more than one attribute with the same name. getAttribute(name) is guaranteed to return zero or one thing. getChildElements(name) is not.







Archive powered by MHonArc 2.6.24.

Top of Page