[jdom-interest] setText() to replace children?
guru at stinky.com
Tue Jul 10 08:50:58 PDT 2001
At 6:27 PM -0500 7/9/01, Brett McLaughlin wrote:
>>One item in the TODO file:
>>* Consider if setText() should not replace children
>>I think setText() should set the text of the element, removing any other
>>text in the element. However, I don't think any other children (such as PIs,
>>comments, etc) should be affected. Does anyone agree/disagree?
This leaves the behavior ambiguous. Should the existing children be moved to
the front, or the end? What happens to whitespace between two comments?
The current behavior is unambiguous. "This sets the content of the element
to be the text given. All existing text content and non-text context is
removed." Anyone who wants to preserve existing content can play with their
own lists (much more intelligently than we can).
Elliotte Rusty Harold wrote:
> I disagree. It should either replace all content or throw an exception.
But it shouldn't replace just some part of the content.
> Actually, here's an idea: suppose we remove setText() completely and
replace it with this overloaded method:
> public Element setContent(String text)
This name would be fine with me, since it reinforces that all content will
In fact, it opens the door to a new set of polymorphic methods, just like
Element setContent(Comment comment)
Element setContent(Element element)
Element setContent(EntityRef entity)
Element setContent(ProcessingInstruction pi)
Element setContent(String text)
to go with
Element setContent(List content)
all of which replace the entire content of the element.
I think that is natural, and will make up for the loss of setText.
Alex Rosen wrote:
> The only problem with all these proposals is the lack of symmetry. If you get
> text by calling getText(), it's natural to set it via setText(), and if that's
> not the name of the method, you have to go looking for it, and figure out if it
> really does what you want it to do. Similarly for setContent() and
> setChildren(). Whether that's a good enough reason to keep the current state of
> things, I don't know. I really like the intuitiveness of setText(), though. In
> the common case where you don't have mixed content, it feels a lot more
I think the API lost nomenclature symmetry a long time ago :-) (see any
thread on "getChildren").
getText() isn't really an accessor though. There is no property of Element
called "text." Rather, it's a utility method that iterates through content
and concatenates some children while throwing others away. At best you
could think of it as a read-only, derived property. Hence there should be no
setText method, reinforcing that it's a read-only property.
I share Alex's intuition about setText though. It's just a nice name for
the method. However, with its other setContent friends it won't be lonely
with its new name :-)
Alex Chaffee mailto:alex at jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
More information about the jdom-interest