[jdom-interest] insertChild in Element

[trebor.a.rude at lmco.com]

	The counter to the argument against add() and such is that we
actually return a PartialList (a JDOM-implemented subclass of LinkedList),
so its implementations of the questionable functions could be changed to
disallow anything "bad". The whole notion of a "live" list takes a little
getting used to (simply because you just don't see it that often), but once
you understand it, it makes a lot of sense. In my mind, the main argument
for making Element implement List would be that the model would then be
closer to the DOM, easing the transition for those used to that API.  But
the function names of the List interface don't really make it clear that
you're operating on children, as the functions in the DOM do. All in all, I
don't think that compatibility with the DOM is that important, and in fact,
I think it might be best if we removed some of the existing functions from
Element (addContent/removeContent), and let those go through the list too.

Trebor A. Rude
trebor.a.rude at lmco.com

> -----Original Message-----
> From:	Scott Ellsworth [SMTP:scott at alodar.com]
> Sent:	Thursday, August 31, 2000 8:56 AM
> To:	jdom-interest at jdom.org
> Subject:	Re: [jdom-interest] insertChild in Element
> 
> 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
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourh
> ost.com