On 10/15/2013 09:40 AM, Sönke Ludwig wrote: > Am 14.10.2013 20:24, schrieb Robert Schadek: >> On 10/14/2013 04:44 PM, Sönke Ludwig wrote: >>> 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. Than I'm not sure what you're referring to.
> 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. > maybe something like: auto devLogger = new StdIOLogger(LogLevel.info); auto appLogger = new FencySelfWrittenGuiLogger(LogLevel.Warning); auto multiLogger = new MultiLogger(devLogger, appLogger); multiLogger.log("..."); otherwise, I think I don't follow you