[jdom-interest] API Inertia

[Steven D. Keens]

-----Original Message-----
From: Steven D. Keens [mailto:skeens at planetfred.com]
Sent: Tuesday, May 01, 2001 14:07
To: Elliotte Rusty Harold
Subject: RE: [jdom-interest] API Inertia


>At 11:37 PM -0700 4/30/01, Jason Hunter wrote:
>
>>Brett, you know me better than to think I make silly arguments.  It's
>>not that I'm worried about the "XMLOutputter internals".  It's that I'm
>>worried about exposing a *false* API.  If XMLOutputter has an
>>output(Node) method and in reality it can't output Amy's funky
>>Node-implementing classes which she wants to write, then it's *lying*
>>about what it can output.  An output(Node) method only makes sense if
>>Node has a way to help the output, as if Node had a getSerializedForm()
>>method.  But you want to use this to *avoid* getSerializedForm().  So
>>you're stuck.
>>
>
>I think I see a way around that. We do make Node implement 
>getSerializedForm(). We make that method take as an argument an 
>object which provides all the current state of the outputter (e.g. 
>whether to pretty print, whether to use empty element tags, where to 
>break lines, etc.). Then we do have XMLOutputter depend on 
>getSerializedForm() in the nodes.

The idea is good but it would be better to pass in a new object
type.  Something like a format object which could be named
XMLFormat.  So the method would be
	String getSerializedForm( XMLFormat );
Maybe my class name is wrong but passing in a bunch of parameters
is bad because there is no way to add new parameters once
the API is finalized.