[jdom-interest] XMLOutputter naming questions

[Ryan Leavengood]

> Louis, Rusty -- the method is called "output" because the class is
> called "XMLOutputter."  It outputs XML.  If you think "output" has to
> change something outside the VM, well, that's a different metaphor
> than is in effect here.  Every process in computer science has input
> and output; the parameters are the input to a method; and so on.  I
> think in this case "output" means org.jdom.output means "classes that
> output from the JDOM library" just like org.jdom.input means "input
> something into JDOM."

I think what Rusty was saying is that the concept of a method that returns a
String given a Element or Document isn't really the same kind of "output" as
when writing to OutputStreams or Writers.  I agree.  It seems to me that the
kind of functionality your adding should be present already in the
Element.toString() and Document.toString() methods.  But I could be wrong
since I don't know exactly what use cases you are trying to satisfy here.
But in general I don't think API redundancy is good (having methods in
different classes doing the same exact thing.)  How do the Strings in the
following code fragment differ??

   // Assume we already have an Element, el
   String s = el.toString(); // Easy

   // Create a new object for some reason
   XMLOutputter outputter = new XMLOutputter();
   String s2 = outputter.outputString(el);

   if (!s2.equals(s))
   {
      System.out.println("Why?");
   }

Now if XMLOutputter is bringing some special knowledge to the table that
allows it to create "better" String representations than the toString()'s
then I could see the reasoning for it.  Otherwise it seems redundant.  But
if you do include it, I agree with Rusty that a name like buildString()
makes better sense than outputString() since your actually building and
returning a String not outputting it somewhere.

> I especially don'g like "toString(Document)" because toString means
> "turn the object into a string" but here the object is the
> XMLOutputter itself.  'toString(x)' would then by extension mean "turn
> the XMLOutputter into a String based on x" which is not what's going
> on here.
>
> (XMLOutputter.toString() would return a string with the states of the
> properties; overloading should not change the high-level semantics of
> a method, just its parameters.)

I agree with this completely.

>  - A

= R y a n =