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.
But denis why this is not for a certain kind of subclass
You have Log with the minimal information (timestamp and an object)
then you can have logger with levels and other.
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.
why?
MySpecialLog
...
emit
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.
In the minimalLog
MinimalLog
object: MyCoolObject new;
emit
no need of message
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
situation.
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.
