std.log available for viewing

[Andrei Alexandrescu]

On 5/28/11 6:40 PM, Jose Armando Garcia wrote:
> The implementation and documentation for std.log is ready for viewing.
> You can take a look at the doc at
> http://jsancio.github.com/phobos/phobos/std_log.html. The source code
> is at https://github.com/jsancio/phobos/blob/master/std/log.d.
>
> I had to make some changes to druntime to get the thread id. The
> module will work without the changes but you wont to see thread ids in
> your log messages. I will look into sending a pull request to
> druntime, in the meantime you can apply the attached patch to your
> druntime if you want to see thread ids in the log.
>
> Let me know if you have any comments or suggestions! Thanks,
> -Jose

1. The fatal log should never be stripped. This is because execution of 
code after using fatal depends on compile-time flags, which is 
unacceptable. Logging to fatal should terminate the application 
regardless of circumstances. Otherwise people would need to write things 
like:

fatal("blah");
assert(0, "Execution cannot continue even though logging is stripped");

This is needless and bug-prone. Fatal is fatal.

2. A critical log that (always) throws might encourage disciplined use 
of exceptions - and with good messages. BTW the log message should be 
present in the exception object too!

3. Why doesn't vlog take the __LINE__ too?

4. initLogging and initializeLogging are highly confusing names. 
Overload them to share the same name, or rename one.

5. Time should be not expressed as long.

6. The riches of XxxConfig types form a sudden swell difficult to 
justify. What is the justification of FilterConfig, VerboseConfig, and 
LoggerConfig? They don't even make sense as nouns or noun phrases. 
Anyhow, a simple approach to design would be: if you need to configure 
some already-created object you'd do so by calling methods of that 
object, and if you need to configure an object just before creating it, 
some factory pattern might be of use. Probably configuration after 
construction is the election approach for this case.

7. The design pushes formatting down to the dynamic interface. That 
might be the right thing but prevents the front end from configuring 
formatting, thus complicating matters for the user. The implementer is 
also aggravated because they need to implement formatting code 
themselves. (As far as I can tell, formatting is not formally offered by 
the design.) This latter issue could be solved by inserting a 
lower-level interface that only transports strings, and a stock 
implementation of a formatting object; but that complicates the design.


Thanks,

Andrei