[jdom-interest] insertChild in Element

[Oliver Imbusch]

>>>>> "jwh" == James W. Howe <jwh at allencreek.com> writes:
>>>>> "jh" == Jason Hunter <jhunter at collab.net> writes:

    jh> I think it's better to give people access to the List for them
    jh> to manipulate as they like than reproduce all the List
    jh> functionality in Element.

    jwh> This is where I would disagree.

I totally agree with Jason.

    jwh> If it is appropriate for someone to be able to manipulate the
    jwh> children of an Element, it should be done through the Element
    jwh> itself, not through some third party object.

What you call a 'third party object' is in fact one Java's core
classes, IMHO. One that I know very well, one I have written useful
methods for. We all know that funny org.w3c.dom.NodeList. I hate it. I
always have to go to the doc to know method names. I have written a
java.util.Iterator class wrapper for it. It's absolutly great that I
get a List from JDOM's Element.

    jwh> Element should support any and all methods which are
    jwh> appropriate to manipulating its internal state. If that means
    jwh> duplicating the List protocol, so be it.

If it duplicates the List protocol, it still isn't a List and thus
cannot be used as such. All methods dealing with Lists accept
java.util.Lists as parameters (or return them), not something that
duplicates the protocol.

By the way, what are the real benefits of the doubling approach? You
don't reach "good style for object-oriented programs" if you blindly
follow some rules of thumb. Every good designer reserves the right to
explicitly break even his/her own laws which protect you from making
the simple errors in 97% of all cases. There are 3% left, at
least. This is such a case. The practical advantages (ease of use,
speed of development, reusing of heavily tested code) of giving the
'internal' List away by far outweights your more or less theoretical
arguments, though encapsulation is The Right Thing(TM) most of the
time, of course.

But: Element should not implement the List protocol. In the same way
it 'is a' List of children, it 'is a' List of attributes. Should all
the List methods follow the child or the attribute axis?

(ceterum censeo: getAttributes() should return a Map; if you want
preserve the order for round trip, use a LinkedHashMap from JPDA;
maybe Sun will replace its current HashMap implementation with that
some day. BTW, for those who want implement both the Map and List
interfaces: that's not possible, see
http://developer.java.sun.com/developer/bugParade/bugs/4187872.html).

-Oliver