PrintStream is an
OutputStream, so you can wrap
stdout into a
Interesting. A poor man’s type class.
I’m not really convinced. A dot file is a textual representation of a graph with a given character set. Given
PrintStream adds functionality to another output stream, namely the ability to print representations of various data values conveniently.
Abstract class for writing to character streams. [
…the latter sounds like a better conceptual fit to me. Some of the required functionality for writing textual data has indeed been added to
PrintStream as an afterthought, but it’s not the recommended abstraction:
PrintStream is, in other words, provided primarily for use in debugging and for compatibility with existing code.
That being said, I think the actual problem with a proper abstraction for both writing a dot file and dumping it to
stdout is the mismatch between a limited set of legal encodings for the file and a fixed encoding for
To make sure that I write proper dot files, I’d like to accept a raw
OutputStream and enforce a legal encoding by wrapping a
Writer around it myself (and specifying this encoding in the dot file as a graph attribute). If I do this with
stdout, however, this may garble output if the system encoding is not the same as the one chosen for dot. If I accept a
Writer (or a
PrintStream) instead, I have to trust the caller to have configured a proper encoding (and I’d be much less confident declaring the
charset attribute in the dot file).
I don’t see a “perfect” solution here. Given this choice, I’d probably rather go with option 1, force the encoding on an
OutputStream and accept the risk of garbling console output if this stream happens to be