Thanks for sending this... after looking at the examples and thinking again about our conversation I may have shifted a bit :-\
I think it's important *log() should only be used for messages intended to be logged! (i.e. read later as a sequence of log messages).
We happen to write these to stderr by default, but this is an implementation detail that I'd like to leave flexible.
So a good question is: "if we were writing the log to a different file instead, would we want to write this there or stderr?"
By that measure:
- the messages followed by exit() should go to stderr
- dexp's output should go to stder
- the others seem good to go to the log
|101 ↗||(On Diff #281027)|
this is fine, but just writes to errs with no log formatting... you need to set up a logger if you want one.
|185 ↗||(On Diff #281027)|
hmm... since this is explicitly supposed to be an interactive tool, I think "we are writing to stderr" is important rather than a detail to be abstracted.
e.g. there's no timestamp etc decoration (which is good!) because you haven't installed an actual logger and the fallback behavior is to write to stderr. But neither of these things are explicit at the callsite and either could be changed elsewhere.
I'd suggest this is log() rather than vlog() - the port is sometimes important to know but *progress through the startup sequence* is useful to have in the log.
Don't use elog before the logger is set up to print messages to stderr - it seems needlessly confusing where the current version is very clear.
(it *is* better for the basic validation to happen early and us to log flag failures "before the stream enters log mode" where it's convenient)
this isn't an error, and we're explicitly trying to get it in front of the user *before* the log starts
explain why or just delete this comment
nit: move this down after flag validation?
I'm not sure performance matters here (if you don't actually write to stdout much, it should be free). Rather, this is for correctness: it's not threadsafe.