[jdom-interest] Is JDOM dying?

[Stephan Trebels]

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.


disclaimer:
  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
  question.


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
rejected.  

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
reference). 


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.

Stephan

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