xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

RE: [XOM-interest] ParentNode.insertbefore and insertAfter

From: "McEniry, Michael" <mmceniry AT itsc.uah.edu>
To: "Elliotte Rusty Harold" <elharo AT metalab.unc.edu>, <xom-interest AT lists.ibiblio.org>
Subject: RE: [XOM-interest] ParentNode.insertbefore and insertAfter
Date: Wed, 9 Apr 2003 17:15:24 -0500

If you allowed negative indices to mean "from the end" (like perl
or python) then you could drop appendChild too.

-- michael mceniry

-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo AT metalab.unc.edu]

Is anybody using the insertBefore and insertAfter methods heavily? If
so for what applications?
>From elharo AT metalab.unc.edu Thu Apr 10 07:45:32 2003
Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id F184120026
for <xom-interest AT lists.ibiblio.org>;
Thu, 10 Apr 2003 07:45:31 -0400 (EDT)
Received: (qmail 28335 invoked from network); 10 Apr 2003 11:45:31 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail15.speakeasy.net (qmail-ldap-1.03) with SMTP
for <mmceniry AT itsc.uah.edu>; 10 Apr 2003 11:45:31 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330114baba89136fbd@[192.168.254.4]>
In-Reply-To: <E05C39DBFF41854D9DC891EDC9DAE58A722DBF AT home.itsc.uah.edu>
References: <E05C39DBFF41854D9DC891EDC9DAE58A722DBF AT home.itsc.uah.edu>
Date: Wed, 9 Apr 2003 22:38:22 -0400
To: "McEniry, Michael" <mmceniry AT itsc.uah.edu>,
<xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: RE: [XOM-interest] ParentNode.insertbefore and insertAfter
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 11:45:32 -0000

At 5:15 PM -0500 4/9/03, McEniry, Michael wrote:
>If you allowed negative indices to mean "from the end" (like perl
>or python) then you could drop appendChild too.

That might make sense to a Perl or a Pythin programmer. To me as a
Java programmer though it feels weird. I do use appendChild() all the
time myself, so I don't think it's going anywhere. It may not be
absolutely necessary, but it is frequently convenient, and generally
more obvious than the alternative. element.appendChild(x) is more
clear than element.insertChild(7) or
element.insertChild(element.getChildCount()).
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
>From elharo AT metalab.unc.edu Thu Apr 10 08:56:28 2003
Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 912E82006A
for <xom-interest AT lists.ibiblio.org>;
Thu, 10 Apr 2003 08:56:25 -0400 (EDT)
Received: (qmail 17891 invoked from network); 10 Apr 2003 12:56:24 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP
for <todd.trimmer AT trizetto.com>; 10 Apr 2003 12:56:24 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330102babb0e024f78@[192.168.254.4]>
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D694F@s-coengl-e05>
References: <89297B2626BD5541B479C42E9599B6245D694F@s-coengl-e05>
Date: Thu, 10 Apr 2003 08:12:26 -0400
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>,
"'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: RE: [XOM-interest] Needs hasX(String)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 12:56:28 -0000

At 2:39 PM -0600 4/9/03, Trimmer, Todd wrote:

>And yet getX(int) is exceptional?

Yes, because the most common use case for this style of access is an
indexed loop that runs from 0 to one less than length of the list.
And the second most common use case is positioning an element at or
one after a known position returned by indexOf(). Neither would cause
the exception. It's rare to call getX(5) without having implicitly
justified in code that there is an X at position 5.

getX(key) is a horse of a different color because the programmer has
likely done nothing in advance to verify that the key exists. The
expectation that the key is there comes from knowledge of the
document format (which may well be wrong) not from the program itself.

>And java.util.* consistently considers
>this exceptional (both indexed and keyed)?

java.util's exception handling is a confusing mess of inconsistent
patterns. You can point to it to justify just about any kind of
exception handling or lack thereof you like.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
>From elharo AT metalab.unc.edu Thu Apr 10 08:56:29 2003
Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 9917620023
for <xom-interest AT lists.ibiblio.org>;
Thu, 10 Apr 2003 08:56:27 -0400 (EDT)
Received: (qmail 17913 invoked from network); 10 Apr 2003 12:56:26 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP
for <todd.trimmer AT trizetto.com>; 10 Apr 2003 12:56:26 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330103babb103ad4da@[192.168.254.4]>
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D694E@s-coengl-e05>
References: <89297B2626BD5541B479C42E9599B6245D694E@s-coengl-e05>
Date: Thu, 10 Apr 2003 08:17:00 -0400
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>,
"'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: RE: [XOM-interest] Needs hasX(String)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 12:56:29 -0000

At 2:21 PM -0600 4/9/03, Trimmer, Todd wrote:

>Try
>
>
> c = e.hasAttribute("c") ? e.getAttributeValue("c") : "";

I've never like the ternary operator. For one thing I can never
remember which argument is returned for true and which for false, or
where the side effects are. I much prefer if-else blocks.

>Of course, I really want
>
>
> // getAttributeValue(String name, String uri, String def)
> c = e.getAttributeValue("c", "", "");
>

This is running us off into JDOM territory of every convenience
method imaginable. You can have this if you want it, but you're just
going to have to write the code yourself. XOM takes a more
micro-kernel like approach of giving programmers just enough power to
do everything, but relying on them to decide which usage patterns
they want to enable.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
>From elharo AT metalab.unc.edu Thu Apr 10 08:56:29 2003
Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 58258200C2
for <xom-interest AT lists.ibiblio.org>;
Thu, 10 Apr 2003 08:56:28 -0400 (EDT)
Received: (qmail 17951 invoked from network); 10 Apr 2003 12:56:28 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP
for <RegierAveryJ AT JohnDeere.com>; 10 Apr 2003 12:56:28 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330104babb1184225d@[192.168.254.4]>
In-Reply-To:
<CE5456E81CB8EF4E9DA9E7E8C454918712225A AT edxmb5.jdnet.deere.com>
References: <CE5456E81CB8EF4E9DA9E7E8C454918712225A AT edxmb5.jdnet.deere.com>
Date: Thu, 10 Apr 2003 08:55:10 -0400
To: "Regier Avery J" <RegierAveryJ AT JohnDeere.com>,
"'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: RE: [XOM-interest] Needs hasX(String)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 12:56:29 -0000

At 3:48 PM -0500 4/9/03, Regier Avery J wrote:

>Which XOM makes difficult to do.

All it takes is a simple for loop. What's hard about that?

>*If* XOM actually provided an iterator()
>method on Node or ParentNode the following would be possible using my
>personal already created utility classes:
>
>return new MutatingIterator(node.iterateChildren()) {
> public Object mutate(Object o) {
> return createBusinessObjectFromNode((Node)o);
> }
>};

And then I have to waste a lot of time explaining to people when they
should use the iterator and when they should use indexed access. That
would violate XOM's principle of "There's exactly one way to do it."
which is important for maintaining simplicity.

>Of course, if you want a thread-safe implementation, it gets much more
>complex.

XOM nodes aren't thread-safe. You'd have much bigger problems than
the iterator.

> Yes, I can write it once and put it in my library, but now my
>library depends on XOM instead of just the application, because the XOM API
>isn't complete.

Wouldn't your API depend on XOM anyway? What would you be doing with
these nodes in the iterator if not using XOM methods on them?

>IMHO, adding convenience methods doesn't introduce complexity, it alleviates
>complexity from client code. Complexity arises from complex relationships.
>Convenience methods don't add relationships.

I've seen in JDOM and most other APIs that there is a complexity cost
of size. The larger something is, the harder it is to learn and
understand. Relationships and tight coupling also add complexity, but
size alone can be a problem.

>At the very least you could add some standard iterator classes to the API
>without actually adding the iterateX() methods. If you included the ability
>to mutate to these standard iterator implementations such like:

I could see adding a subpackage of collection adapters along the
lines you propose if I were convinced there were actually a strong
and common need for them. So far I haven't seen a need though. You're
going to have to show me something concrete that cannot easily be
achieved with a basic for-loop.

You're also going to have convince me the loss of type-information is
not a crippling problem. I'm willing to consider that the iterator
pattern may make sense in languages with different powers than Java,
e.g. Python and C++. But in Java I think a confluence of factors
(strong typing, the omission of generics, non-covariant return types)
has severely hobbled the Collections API to the point where it's
often inappropriate. You're going to have to explain to me not just
why I should prefer an iterator to a list but why I should prefer an
iterator of objects to a list of nodes.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
>From jcowan AT reutershealth.com Thu Apr 10 10:12:33 2003
Return-Path: <jcowan AT reutershealth.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from skunk.reutershealth.com (unknown [65.200.144.21])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 5820120054
for <xom-interest AT lists.ibiblio.org>;
Thu, 10 Apr 2003 10:12:33 -0400 (EDT)
Received: from skunk.reutershealth.com (unknown [127.0.0.1])
by skunk.reutershealth.com (Postfix) with SMTP
id DFFEF46E34; Thu, 10 Apr 2003 10:15:02 -0400 (EDT)
Received: by skunk.reutershealth.com (sSMTP sendmail emulation);
Thu, 10 Apr 2003 10:15:01 -0400
Date: Thu, 10 Apr 2003 10:15:01 -0400
From: John Cowan <jcowan AT reutershealth.com>
To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] Needs hasX(String)
Message-ID: <20030410141501.GB23679 AT skunk.reutershealth.com>
References: <89297B2626BD5541B479C42E9599B6245D694E@s-coengl-e05>
<p04330103babb103ad4da@[192.168.254.4]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p04330103babb103ad4da@[192.168.254.4]>
User-Agent: Mutt/1.4i
cc: "Trimmer, Todd" <todd.trimmer AT trizetto.com>
cc: "'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 14:12:33 -0000

Elliotte Rusty Harold scripsit:

> I've never like the ternary operator. For one thing I can never
> remember which argument is returned for true and which for false, or
> where the side effects are. I much prefer if-else blocks.

Huh. The order is precisely if-part, then-part, else-part, which seems
totally intuitive to me.

--
John Cowan jcowan AT reutershealth.com www.reutershealth.com
www.ccil.org/~cowan
Consider the matter of Analytic Philosophy. Dennett and Bennett are
well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites
Dennett.
There is also one Dummett. By their works shall ye know them. However, just
as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is
hardly
known by his works. Indeed, Bummett does not exist. It is part of the
function
of this and other e-mail messages, therefore, to do what they can to create
him.
>From RegierAveryJ AT JohnDeere.com Thu Apr 10 10:52:47 2003
Return-Path: <RegierAveryJ AT JohnDeere.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from fdpnmailgw4.mailgws.com (fdpnmailgw4.dpn.deere.com
[192.43.65.232])
by happyhouse.metalab.unc.edu (Postfix) with SMTP id AAF7120040
for <xom-interest AT lists.ibiblio.org>;
Thu, 10 Apr 2003 10:52:47 -0400 (EDT)
X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1
Message-ID: <CE5456E81CB8EF4E9DA9E7E8C454918712225C AT edxmb5.jdnet.deere.com>
From: "Regier Avery J" <RegierAveryJ AT JohnDeere.com>
To: "'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
Subject: RE: [XOM-interest] Needs hasX(String)
Date: Thu, 10 Apr 2003 09:52:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 128B5ABD639906-01-02
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 14:52:48 -0000

Here's the crux of the matter. ~80% of us out there who are likely to use
XOM have already been using the Collections API for several years. Further
than that, even if we're not using the full Collections API, we've probably
been upgrading our code from using Enumerations to Iterators and providing
ourselves conversion classes between them. Why are we using them? Because
they are there and because they are standard and always available, and hey,
the Iterator pattern does actually make sense too. Lots of people we trust
have been telling us that for years [GOF 257].

So not only do we use it, but most of the other third party API's we use
also have given us iterateX() or enumerateX() methods where they make sense.
And yes, they also provide methods for getting contents based on indexes or
keys. Programmers understand when it is best to use one over the other
because they make those kinds of choices regularly. If the code looks ugly
to them doing it one way, the other way usually provides the clean way in
that situation. By providing only way to do anything you are actually
picking a way that is clean in only some situations and forcing that the
other half our code is going to be ugly.

>>Which XOM makes difficult to do.
>All it takes is a simple for loop. What's hard about that?

Well, I thought I'd actually shown that in the rest of the message.

>> Yes, I can write it once and put it in my library, but now my
>>library depends on XOM instead of just the application, because the XOM
API
>>isn't complete.
>
>Wouldn't your API depend on XOM anyway?

I realized after I sent it that I didn't explain this point well. My
application may rely on XOM but that doesn't mean all applications I write
will rely on XOM. However, all applications I write will likely rely on my
utility library. If my utility library relies on XOM then for every
application I now have to provide XOM (at least in the build process)
whether it uses it or not. At this point, I now need to maintain a seperate
utility library just for XOM. I've already seen this kind of problem with
JUnit and other APIs. These seperate utility libraries then tend not to get
used because they aren't in the core. It would be so much nicer just have
those methods in the actual library.

>What would you be doing with
>these nodes in the iterator if not using XOM methods on them?

Yes, I would be using XOM methods from the Node in my iterator. But that
code would be in my application because I'm dealing with
application-specific data. However, the code to create the iteration logic
itself is not application-specific. The iteration logic is XOM specific,
and that is why I believe it belongs in XOM and not copied into every
application or in a library specific to each programmer that he has to
maintain.

>I could see adding a subpackage of collection adapters along the
>lines you propose if I were convinced there were actually a strong
>and common need for them. So far I haven't seen a need though. You're
>going to have to show me something concrete that cannot easily be
>achieved with a basic for-loop.

I hope I've explained this need at the beginning of this message. It is a
matter of integration ease.

>You're also going to have convince me the loss of type-information is
>not a crippling problem. I'm willing to consider that the iterator
>pattern may make sense in languages with different powers than Java,
>e.g. Python and C++. But in Java I think a confluence of factors
>(strong typing, the omission of generics, non-covariant return types)
>has severely hobbled the Collections API to the point where it's
>often inappropriate. You're going to have to explain to me not just
>why I should prefer an iterator to a list but why I should prefer an
>iterator of objects to a list of nodes.

I completely agree the loss of type-information in the Collections API is a
problem, and that the generics that will be added in 1.5 don't solve the
problem but rather just cover it over with pretty syntax. This is why I've
put into my own library a comprehensive set of adapter classes that make it
really easy to make type-specific iterators that are at the same time also
compatible with standard Iterators, Enumerations, and ListIterators. I'd
prefer to have available an iterator of nodes and a list of nodes. Thus, my
proposal for a NodeIterator would be thus:

public class NodeIterator implements Iterator {
private Node node;
private int pos = 0;

public NodeIterator(Node node) {
this.node = node;
}
public boolean hasNext() {
return pos < size();
}

public Object next() {
return mutate(nextNode());
}

protected Object mutate(Node node) {
return node;
}

/**
* Type specific next() method
*/
public Node nextNode() {
return node.get(pos++);
}

public int size() {
return node.getChildCount();
}

public void remove() {
removeChild(pos);
}
}

public class AttributeIterator implements Iterator {
private Element node;
private int pos = 0;

public NodeIterator(Element node) {
this.node = node;
}
public boolean hasNext() {
return pos < node.getChildCount();
}

public Object next() {
return mutate(nextAttribute());
}

protected Object mutate(Attribute node) {
return node;
}

/**
* Type specific next() method
*/
public Attribute nextAttribute() {
return node.getAttribute(pos++);
}

public int size() {
return node.getAttributeCount();
}

public void remove() {
node.removeAttribute(node.getAttribute(pos));
}
}

And similar for Element. Much refactoring could take place along with also
implementing ListIterator. I did not try to compile the above code.

Re: [XOM-interest] ParentNode.insertbefore and insertAfter, dirk bergstrom, 04/09/2003
- <Possible follow-up(s)>
- RE: [XOM-interest] ParentNode.insertbefore and insertAfter, McEniry, Michael, 04/09/2003