[jdom-interest] XMLOutputter naming questions

[Brett McLaughlin]

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."

Hmmm... I guess the biggest problem is that I can't think of any Java
methods that are called output or outputXXX that /return/ a value. I
could be wrong - I didn't look this up, I'm just going over it in my
head.

> 
> 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.

This is a good argument against toString(), and I agree with it. I can
also see how getString() might be misleading... but usually getXXX means
something will be returned, and therefore fits in here to some degree.

Some fodder:

getString()
getXMLString()
getXML()

... I keep coming up with getXXX ... I can't help it. And I know it
generally refers to properties. If someone can think of something
between get and output, I'm all for it... And I do agree that toXXX
isn't really right, either. printXXX is out, so is writeXXX, as they are
analogs to output that I don't expect to return values.

Maybe generate()? outputter.generate()? I don't know.... or
generateString()... I'm stumped...

However, I'm going to try and push these and the getText() fix into beta
5 (as they are all really needed features), so let's get this resolved
ASAP.

-Brett

> 
> (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.)
> 
>  - A
> 
> 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.
> >
> > Louis
> > --
> >
> > <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
> > Louis Tribble                                         louis at metamata.com
> > Metamata, Inc.                                   http://www.metamata.com
> > Tools for serious Java developers.                       +1 510 796 0915
> > <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
> 
> --
> 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/
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org