Hi Tudor.

I think I super bad in explaining things because you not answer my question.

As you said��we should encourage people to create typed signals. I am not against it. But I try to explain that approach of Beacon is wrong. It is wrong to make this signals be subclasses of Beacon core component BeaconSignal.

We have in Pharo 307 subclasses of Announcements (only 78 have some kind of time variable). Do not they all are signals for logging? But only way how to log them in Beacon is to wrap them by kink of WrapperSignal.
Does my issue is clear now?

At the end we will got logs with mix��of normal events which created specially for logs and WrapperSignal's containing original application events.��


2016-04-28 23:39 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi Denis,

On Apr 28, 2016, at 4:43 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:


2016-04-28 14:51 GMT+02:00 Tudor Girba��<tudor@tudorgirba.com>:
It is not the most elegant solution, but it is very malleable and good enough for debugging purposes. If we would have instance-based filtering for announcements, we could filter based on that without any extra effort. Also, if we would have a composition��mechanism in place, we could build these objects with a more elegant API.

Regarding your statement of logging domain objects, you will have to store these objects with the additional information��somewhere, and that will be a wrapper class. I do not see the difference with the Signal.

Difference with Beacon is that users will not depends on objects from logging library. Nobody needs to subclass core components��like Signal.�� ��
Instead domain objects will be added to logs inside general LogEntry instances which will be hidden from user and only available��inside logs. And LogEntry will allow include additional information to itself by appropriate logging API.��

Question is: does it better?��
And this is what problem I see around Beacon:

Beacon proposes to design log entries as events, as subclasses of BeaconSignal. If nothing else exists it is good. We will see in��logs collection of such events.
But what to do with existing domain events which has no relation to logs? How to log them if we decide to do it?

They can be added to log inside WrapperSignal. But then we will see in logs mix of normal events which created specially for logs��and WrapperSignal's containing original application events.��
But both type of events belong to same application. We definitely want to see them and to work with them in same way everywhere��(especially inside logs)

Tudor what do you think about this problem? Maybe I misunderstood Beacon.

Thanks for the dialogue. I think the most important part is to identify concerns and now we are getting concrete. So, let���s see :).

Your LogEntry is exactly the same as BeaconSignal. There is no difference. You will also need to transport the LogEntry from your application to the logger object. Beacon reuses the Announcement framework to do just that. If you avoid the Announcement framework, you will implement another engine that has essentially the same responsibility. I think it is better to consolidate in this case.

So, I see no downside of using Beacon for your purpose.

But, I think there is more. One example where we have an event that is often worthwhile preserving is an Exception. In Beacon there is an out-of-the-box ExceptionSignal. This is not just a wrapper around the exception, but it also decides what to log from an Exception. For example, in order to ensure that we can have proper navigation of the exception, we capture the RB nodes for each stack entry. This is a naive implementation and we should certainly improve it (for example, we would need to delegate the computation of the stack information as late as possible), but it exemplifies how when you log you want to choose what to log. It can be that in another situation, we want to log the whole context of the exception. Furthermore, because we have a typed signal, we can also have a Stack presentation that depends on the strategy we used to log, not on the object that we logged. I believe this is a recurrent case.

Nothing would prevent us from logging the exception through a plain WrapperSignal either. Only in that case we would not have the extra information that the ExceptionSignal provides. So, from this point of view, the ability to create types of signals is not a limitation, but an added value. That is why in my message I said that we should encourage people to create typed signals, but we should not enforce that.


You mentioned that maybe your event object has a timestamp already. This timestamp is not the same as the logging timestamp, and it should be treated separately. If it is the same, that situation is so rare that I doubt we should optimize the whole framework around such a problem.

Does this make sense?

Cheers,
Doru




--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."