Am 14.10.2013 20:24, schrieb Robert Schadek:
On 10/14/2013 04:44 PM, Sönke Ludwig wrote:
Am 14.10.2013 15:12, schrieb Robert Schadek:
On 10/14/2013 02:39 PM, Sönke Ludwig wrote:
- The static methods in LogManager should be made global and the class
be removed. It's not for objects so it shouldn't be a class.
LogManager also stores the global log level. Sure I can make another
static global function storing this log level, but I would like to keep
them together as they belong together IMO.
The same could be said about the global "log" functions, which are
tightly coupled to that state. I think this is already nicely grouped
together by the logger module itself, since there is not much else in it.
Basically, I just wouldn't consider this style to be particularly
idiomatic D code, but of course that's just personal
perception/preference (there is also some precedence using "struct"
instead of "class" in Druntime). However, if it ends up like this in the
final version, it should get a "@disable this();" to prevent misuse.
It is for ment for phobos not druntime. Anyway structs would mean all
templates and people will scream template bloat. And this would break
the design, which I find to be a valid use of classes and
polymorphisms. The StdIOLogger can have its default constructor called IMO.
No no, I was talking about the JobManager, not the Logger classes. No
templates involved.
- For me this logger is completely worthless without any debug log
levels. The last std.log entry had at least anonymous verbosity
levels, but I'd prefer something like I did in vibe.d [1], where
each level has a defined role. This should especially improve the
situation when multiple libraries are involved.
Logger.log(LogLevel.(d|D)ebug, "Your message");
That would be my idea. Having at least two (diagnostic output for the
user and debug output for the developer), but better all four debug
levels can be very useful, though.
Maybe I miscommunicated what I want to show by that example. The (d|D)
part is the rename to enum lower case.
The debug log level is given through the LogLevel.Debug, which will be
renamed to LogLevel.debug. I would call the developer the user of the
logger. Maybe log messages can be communicated to the user of the
applicaiton and the developer of the application through a MultiLogger
class.
But the statement of mine that you quoted was about debug levels (the
case issue is clear)... Also right now there is no "(D|d)ebug" level, so
I'm actually not sure about the statement that you want to make. But my
example of having different levels for the application user and the
developer is mostly important when the application user enables verbose
log output to see where things go wrong. In that case things like system
error codes and the like would make sense, but a repeated printout of
some kind of internal buffer state would hardly help the user - it
could, however, help the developer.
Thanks for bringing this forward!
To whom is this directed?
To you for attempting to revive the logger topic.
