[jdom-interest] XMLOutputter naming questions

[Louis Tribble]

Alex Chaffee wrote:
> 
> 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 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.)

The toXXX(x) convention for methods that are essentially pure
functions has been comfortable in practice. However, let me 
suggest something else. java.text.Format and its subclasses use 
format(x) methods to return the String and StringBuffer equivalents of x 
(hmmm, this says XMLOutputter could plausibly be called XMLFormat...).

You can also view these methods as factory methods and on that view,
createXXX(x) names are comfortable. 

I don't really mind the getXXX(x) names. However, I do expect methods 
with names like "output", "build", "write", and such to change the state 
of the object or of the external world attached to it. The methods
we are discussing are essentially pure functions from Elements, etc, to
Strings (modulo the configuration state maintained by XMLOutputter).

Louis

> On Mon, Oct 02, 2000 at 12:35:46PM -0700, Louis Tribble wrote:
> > Alex Chaffee wrote:
> > > +1 on outputString, since "get" generally refers to a *property* of
> > > the object, and String is not a property.  "outputString" is more
> > > descriptive of what it's really doing.
> >
> > Ouch.
> >
> > outputString() implies to me that output (some state change to the
> > external environment) is happening, but it isn't.
> >
> > There is some precedent for calling such methods "to<class>()". If, in
> > this case, toString() is not comfortable (because of its presumptive
> > debugging usage), we could fall back to toXMLString(), or some such.
> > For myself, toString() seems fine.