Stanimir Stamenkov wrote:
Why should I suffer from unnecessary encoding (done by the serializer)
then decoding (on my part), further handling character references
generated during the first encoding phase (eventually)?
Seems I'm not following you here. Why one should make a
'WriterOutputStream'?
Again, if one needs to serialize to a byte stream then he needs to use
the 'OutputStream' argument constructor - why should he create an
'WriterOutputSream' and pass it to the 'Writer' argument constructor,
loosing the extra care the serializer does when writing to a byte stream?
What I mean is an opposite to OutputStreamWriter - ie, something that
takes a Writer and wraps it as an OutputStream - then it would seem
rather natural to beginners to use the constructor, and provide an easy
alternative for advanced use.
However, that would not answer your first encoding decoding problem
(although I'm not sure what would drive it).
Eric J. Schwarzenbach wrote:
This has been discussed in these lists before.
However there is one practical problem with deprecating this method. We
cannot assume the developer is serializing to something under his
control and that he has the option of constructing a Stream or a Writer.
He may he interfacing to another system which provides him only a Writer
to serialize to. OutputStreamWriter offers a bridge from OutputStreams
to Writers but as far as I know there is no bridge the other way.
Well, I have a new (and betterer!) idea. Is it possible to remove the
OutputFormat argument? I reckon that's dishonest. I would suggest
enforcing something like:
Document doc = ...;
Writer output = ...;
OutputFormat format = new OutputFormat(doc, encoding, true);
output.write(format.generateHeader())
new XMLSerializer( output ).serialize(doc.getDocumentElement);
This way, it enforces that the user understands what they are doing, and
does not take an encoding and do practically nothing with it. And it
would be fail-fast - if they didn't add the header, they would know
about it pretty quick [as opposed to the current situation...].
Or, a boolean could be added to the writer constructor to specify
whether to encode the output - that would at least force the question
"what on earth is that boolean there for?".
See? Two easy and declarative options that indicate what it would do
:). Plleeeeeeeeeaaase deprecate! If nothing else, it annoys me to see
a dishonest api.
Ok - thank you both for your time - I wish I could have just searched
the archives to pick up the argument for the reasoning behind it. I
hope this has been thought provoking for you guys.
Cheers
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
