4 ms·
Surely it depends where your output is going? Print and friends are ideal for producing human-readable output, especially when it is temporary, for monitoring
by cillian64 10y ago
Surely it depends where your output is going? Print and friends are ideal for producing human-readable output, especially when it is temporary, for monitoring or debugging. And they are awful for producing stable machine-readable output which you might want to store.
If I'm trying to output straight to a user sitting in front of a terminal, they are going to be very unhappy if I output XML at them. And if my program only outputs machine-readable and requires another layer to turn it into something human-readable, that seems overcomplicated for most applications.
Have I missed the point, or is this advice intended for more specific scenarios than I imagined?
- superuser2 10y agoI think the point is to use a serialization library when you are trying to output a structured format rather than writing a half-assed use-case-specific implementation of one. Print and friends are appropriate when not attempting to produce data that conforms to any particular structured format.
- 0xcde4c3db 10y agoI think the benefit of a serialization library is going to depend on how complex and dynamic your actual output is. I've done XML-by-printing, but in that case the XML elements were fixed scaffolding with no relation to our internal object hierarchy (A containing array of B containing array of C containing array of D, always, regardless of how our application changed). It was also on an embedded system for which adding libraries was kind of painful.
- spdionis 10y agoIf I need to communicate with a couple of external endpoints that need 5-10 lines of mostly static xml amd the templating is simple i often might prefer using a static templated xml file. It's much easier to understand what's happening later.