[jdom-interest] XMLOutputter naming questions
ryan at wctravel.com
Mon Oct 2 15:02:43 PDT 2000
> 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);
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 =
More information about the jdom-interest