On Mon, Mar 5, 2012 at 1:55 PM, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
> On Mon, 13 Feb 2012 10:50:04 -0500, David Nadlinger <s...@klickverbot.at>
> wrote:
>
>> There are several modules in the review queue right now, and to get things
>> going, I have volunteered to manage the review of Jose's std.log proposal.
>> Barring any objections, the review period starts now and ends in three
>> weeks, on March 6th, followed by a week of voting.
>
>
>
> Some notes:
>
> I dislike that logging affects function execution. In particular, I don't
> think the logging library should have any business throwing exceptions or
> errors. It should be invisible to the application. The equivalent function
> can be had by giving a wrapper function (i.e. log this message at the fatal
> level, and then throw an error). A use case I can see is printing several
> fatal log messages before exiting.
>
Then don't use std.log.fatal. It is not like you are forced to use it.
You can implement the above by using std.log.error
> The log aliases use names that are too common. I think log.info is a better
> symbol for logging than just 'info', which could be a symbol in a myriad of
> places. Given that D's symbol lookup rules allow shadowing of global
> symbols, this does not work out very well.
>
This is a tough one. Should we be relying on D's module abstraction.
It is not scalable as a module designer and implementer to think about
other modules. This is why a lot of programming languages implement
the concept of namespaces.
import log = std.log;
log.info("hello world");
> Like others have stated, I think vlog is a) confusing, and b) unnecessary.
> Even reading the docs, I can't understand what it's used for, and why it
> has such different syntax than the normal logging stuff.
>
I have tried to explain this before but it looks like I have failed. I
find it useful. If you are interested on a different explaination:
http://google-glog.googlecode.com/svn/trunk/doc/glog.html
> I really like the every function, that's a great idea, one that I've
> manually implemented (at least the once every N times) many times.
>
Great!
> Do we have to make the logger a singleton? I'd like to see cases where I
> can have different log instances. For example, an instance I can
> enable/disable per class type, or an instance that logs to a diffferent
> backend. Or a non-shared instance which does not need to handle threading
> issues (i.e. a per-thread file log). Does this help with the vlog issue?
>
My point of view here is that as a developer I never know how I want
to categorize my log during development. Some people use class name as
a hack for doing this. What about functional programs that don't use
class/objects? What about logical component/classes that span multiple
classes? I always found class based grouping for logging as a hack. D
made the observation that classes are not always the best abstraction
unit so it introduced modules. std.log filters based on modules
(actually source files to be exact but if D had __MODULE__, std.log
would use that instead.)
> -Steve
