[Pharo-dev] Logging API discussion
dionisiydk at gmail.com
Tue Apr 26 11:28:31 EDT 2016
2016-04-26 15:36 GMT+02:00 Tudor Girba <tudor at tudorgirba.com>:
> > Let's think about logging API to log any object in the system. Most
> natural way is just send message #log to object itself:
> > anObject log
> > It would be nice replacement for Object>>logCr.
> This type of usage should be discouraged in my opinion. We should instead
> encourage people to use typed logging signals, like we should also
> discourage people from using
> self error: ‘a magic string here’.
> > But when we log some information we usually want to log it with little
> remark, importance level and (most important) timestamp. This information
> is kind of standard for logging domain. But it requires much more methods
> for logging API.
> > So we need extra information to put together with objects:
> > • timestamp
> > • user message
> > • importance level (debug, info, error, etc.)
> Please do not do that. This might make sense for C or Java (although it
> does not), but we have objects and we should filter based on those without
> relying on a rigid system based on random levels. Please.
Before I start to think about logging I was agree with you. Now I am not.
This kind of information belongs to logging domain. It can be retrieved
from application objects as default values but at the end it should be
explicit part of log entries. We can read it in logs for every record to
realize when and why object was added to log, what this record is about.
And you say let's replace this "log object context" information with first
class entities "typed signals". It means that for any possible case when I
want to put something in log I should create class for new signal. It's
just not practical.
Beacon introduce WrapperSignal to solve it. But it only provides target and
timestamp. What I should do if I want to put little remark for my object?
And what if I want to put little remark for ThisContextSignal?
My idea that logging should be as simple as possible and we not need
another "everything is signal" concept here: it is restriction. Everything
is object. And every object should be able to log.
And about random log levels. Their purpose is to mark log entries with
importance level which is useful to explore logs.
Imaging we have system which produce some events and we log them. (My and
your approaches allow it. Only difference that in my approach this event
will be part of log entry (as composition) and with your approach this
event will be log entry itself).
Now imagine that we need to explore some problem situation when particular
events are appeared but they should not. I would try to find wrong places
in code where events can be signalled and I would log them their.
With my approach I will log them with specific importance level (#warning)
and specific message to distinguish them from normal events. With my API it
is super easy.
With your approach I will need to create new classes to signal this
Also my approach allows me to configure in advance my application to put
warnings in separate log. So I will not need to change app configs to
simplify experiment. I will just deploy new code with extra logging and
wait results in ready to use log.
My proposals are not opposite to your. I just not put extra restrictions.
Beacon can be based on top of it but not vice versa.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev