[jdom-interest] insertChild in Element

[Scott Ellsworth]

At 08:51 AM 8/31/2000 -0400, James W. Howe wrote:
>At 06:31 PM 8/30/2000 +0200, Jason Hunter wrote:
>> > It seems to me that the ability to insert a child into an
>> > Element at a particular location is behavior which belongs to the
>> > Element itself.  I
>> > would advocate adding this capability to Element.
>>
>>Then you need the ability to remove a particular child by index too.
>>And the ability to remove all children, remove a child by name, remove
>>all children with a name, add a set of children, remove a set of
>>children, and so on.
>>
>>All these things are easily done with the List returned by getChildren()
>>using standard Java APIs.  I think it's better to give people access to
>>the List for them to manipulate as they like than reproduce all the List
>>functionality in Element.
>
>This is where I would disagree.  If it is appropriate for someone to be 
>able to manipulate the children of an Element, it should be done through 
>the Element itself, not through some third party object.  Element should 
>support any and all methods which are appropriate to manipulating its 
>internal state.  If that means duplicating the List protocol, so be it.

I agree with Jason, I believe, in that returning a live list seems like a 
perfectly good way of exposing the API - the methods that affect the 
internal state are those in Element and those in the underlying list.  For 
me, this is a reasonable way to organize things.

The best counter argument for this would be a list of methods in List that 
are inappropriate for Element.  The obvious one is add - once you get the 
underlying list, it would not be hard to add something like an output 
stream.  Still, to me, the object design seems reasonably clean, in that 
the limits are documented, and we can always add some kind of fail fast 
checking.  The question becomes how many other such methods are there in 
List, and what should we do about them.

To me, the relationship is implemented-in-terms-of, which is a subset of 
has-a, so I would rather not see Element implement list, and I prefer to 
give out the list rather than duplicate.  By exposing the List api, we give 
a fair amount of power and flexibility.  The best reason not to do so would 
be if some of that power and flexibility encourages things we do not wish 
to encourage.

Scott
Scott Ellsworth
scott at alodar.com