[jdom-interest] Is JDOM dying?
stephan at ncube.de
Fri Mar 14 08:19:34 PST 2003
Here I am as advocatus diaboli even though I'm nearly sure I'd never use
it myself ;-/ But alas, this is a technical discussion not a religious
war - I hope.
I'm sure, that normally it makes more sense to use an explicit
namespace in all Elements. This is definitely true for all my work
areas where mutable Elements would be a nightmare. This is not in
But we have to face, that some people want to use Elements differently.
So I'd ask whether it is possible to make everyone happy without
sacrificing anything essential.
In my compromise not a single line of code using JDOM anyone had have
written would be invalidated or behave any different. The namespace set
by new Element(String) should not be changed - that should definitely be
The only added feature would be, that you CAN use a special Namespace
constant for different _output_ behaviour. The only code changes would
have to be in the outputters.
So I ask you: Why/How would this make the API any uglier? The API isn't
changed a bit. The only way to get the changed behaviour would be to
use a static constant in the Namespace class, which can be documented
"for special applications, only". It shouldn't even be documented in a
user's guide (this would be something for a special addendum in the
My personal opinion about an API is, that it should be easy to use and
easy to learn, agreed. Not all tasks need to be available in the
entry-level API, but ultimately all possible tasks should be made as
easy as possible.
On Fri, 2003-03-14 at 13:46, Elliotte Rusty Harold wrote:
> At 8:56 AM +0100 3/14/03, Stephan Trebels wrote:
> >Would it be a workable compromise to have a Namespace.INHERIT for an
> >Element as a possible namespace argument?
> I wouldn't accept such a compromise. It's ugly. Right now the JDOM
> namespace story is clean and consistent. This proposal says it
> changes depending on whether or not you set Namespace.INHERIT. Too
> many options just create a baroque API that's hard to learn, hard to
> teach, and hard to use. Generally when faced with two possible ways
> of accomplishing something, it's better to pick one than to pick both.
Stephan Trebels <stephan at ncube.de> Consultant
company: nCUBE Deutschland GmbH, Hanauer Str. 56, 80992 Munich, Germany
phone: cell:+49 172 8433111 office:+49 89 1498930 fax:+49 89 14989350
More information about the jdom-interest