FW: [jdom-interest] Text class (Modified)

Amy Lewis amyzing at talsever.com
Thu May 31 19:51:06 PDT 2001

On Thu, May 31, 2001 at 09:13:52PM -0500, Brett McLaughlin wrote:
>Thoughts on what's below?
>> From: Alex Rosen [mailto:arosen at silverstream.com]
>> Sent: Thursday, May 31, 2001 7:41 PM
>> To: 'Brett McLaughlin'
>> Subject: RE: [jdom-interest] Text class (Modified)
>> It's probably also worthwhile to implement Comparable. (Seems 
>> like the right
>> thing to do.)

Really worthwhile?  Is it going to do anything other than
Collator.getInstance().compare(someString, node.getValue()) ?

If Text implements Comparable, then I'll raise the question: should
other node classes (admitting that there still is no such thing as a
JDOM node, but the concept is there, if the interface isn't) also
implement Comparable?  Is there a useful compare() for elements?  The
standard text compare works for attributes, although it works best as
compare(att.getName() + "=" + att.getValue(), att2.getName() + "=" +
att2.getValue()), but that isn't always what the user wants, so it
isn't (despite my comment) "best".  In fact, the same sorta goes for
Text, since some comparisons may want to take the element parent into
account, some may want to concatenate all text node and CDATA children
of a single node, some may want XPath-ish string-value semantics for
comparison ...

In short, no.  I don't see that a simple implementation is a good
value-add, and a more complex one can't easily meet all user needs for
all cases.  So best not to implement, but leave it to the developer. 
Text nodes aren't, as a rule, sorted.  It isn't a critical feature.

Amelia A. Lewis          alicorn at mindspring.com          amyzing at talsever.com
  "Ruby fruit jungle?"
  "Yeah, women are thick and rich and full of hidden treasures and besides
that, they taste good."
					-- Rita Mae Brown, "Rubyfruit Jungle"

More information about the jdom-interest mailing list