[jdom-interest] Important proposal: Element/Document changes

[Jason Hunter]

tsasala at hifusion.com wrote:
> 
>         Two comments:  is it possible to deprecate the methods instead
> of removing them?  We have application code that relies on JDOM, despite
> the fact it is beta :).  

I personally would be OK with deprecating for one beta round to give you
time to change.  However, I'm firm there will be NO deprecated methods
present in 1.0 final.

> Secondly, how about a replaceChild or at least
> an addChildAt method?  It's trivial, but order makes a huge difference
> to our application, so removeChild/addChild just doesn't work.
> Other than that, I'm generally in favor of the changes.

I can see a good use case for replaceChild() for tools like XMLC that do
that all the time.  Would it be replaceChild() or replaceContent()?  I
lean toward replaceChild(Element,Element).  replaceContent() would need
5*5 versions depending on what you wanted to replace with what. 
Replacing an element with an element is probably the far more common use
case, and that should be called replaceChild().

Then the other method you propose would be addContentAt().  That's
probably better as a Content form rather than Child form.  Hmm, we'd
need five forms again to cover all bases.  What's the compelling common
use case here?

>         I like the simplicity of getChildren/getChild over
> getChildElement etc.

OK.  Others agree or disagree?

-jh-