[jdom-interest] attr.getXXXValue

Joseph Bowbeer jozart at csi.com
Wed Jul 19 15:04:53 PDT 2000

I like both the getXXXValue() and the getXXXValue(default) methods
of Attribute, provided that the 'default' version throws a
conversion exception if the attribute string is in an invalid
format.  (But what if the attribute string is ""?)

Since the decision of whether to represent something as content or
as an attribute is often a matter of taste (i.e., arbitrary), I
think it would also be convenient to provide getXXXContent methods
for Element.  And getXXXContent(default) methods naturally
follow...  But what rules would we use regarding the whitespace in
the content (if any).

Joe Bowbeer

Received: from slim.silverstream.com ([])
	by dorothy.denveronline.net (8.9.3/8.9.3) with ESMTP id NAA16360
	for <jdom-interest at jdom.org>; Wed, 19 Jul 2000 13:36:56 -0600 (MDT)
Received: by slim.silverstream.com with Internet Mail Service (5.5.2650.21)
	id <3PRYATGD>; Wed, 19 Jul 2000 15:36:49 -0400
Received: from arosen ( []) by slim.silverstream.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 3PRYATGB; Wed, 19 Jul 2000 15:36:43 -0400
From: "Rosen, Alex" <arosen at silverstream.com>
To: jdom-interest at jdom.org
Subject: Re: [jdom-interest] More changes
Date: Wed, 19 Jul 2000 15:38:24 -0400
Message-ID: <003c01bff1b8$e7c1af90$8064810a at silverstream.com>
MIME-Version: 1.0
Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <200007191648.KAA04882 at dorothy.denveronline.net>
Sender: jdom-interest-admin at jdom.org
Errors-To: jdom-interest-admin at jdom.org
X-BeenThere: jdom-interest at jdom.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: JDOM Mailing List for General Issues and Updates <jdom-interest.jdom.org>

It certainly seems like the right thing that getIntContent() and getIntValue()
should throw an exception when the format is wrong. This is separate from the
question of whether they should exist at all. I would sorely miss them.

We created a hierarchical data format before XML was created, which we call
"MetaData". The API is very similar to the current JDOM. Since DOM is such a
pain to use, we now use MetaData as a front-end whenever accessing XML. I'd love
to switch over to JDOM, since it's more standard, and a more direct mapping to
XML than our MetaData API. But our API includes typed data access, and it would
be much harder to get people to switch over if that went away.

> I've come to believe these methods are unimportant syntactic sugar,
> that add complexity to the API while providing no real benefit to
> most programmers. The smaller JDOM is, the  simpler and easier it is
> to learn and document. 80+ methods in a class simply looks too
> intimidating even if you can ignore most of them most of the time.
> I'd simply rather have fewer methods in the class.

I'm certainly very sympathetic to this point of view. Simpler and smaller is
easier. But while I agree that these methods are syntactic sugar, I very much
disagree that they are unimportant syntactic sugar. To me, they are the
difference between very readable code and only moderately readable code. In our
particular case, it would be very much worth the tradeoff of a larger API for
more convenience and readability. That certainly doesn't mean that that applies
to everyone, but it's one datapoint.


More information about the jdom-interest mailing list