Hi Tudor.

2016-04-26 15:36 GMT+02:00 Tudor Girba <tudor@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 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.