Hi Denis,
On Apr 27, 2016, at 2:16 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert@hartl.name>: I must confess I cannot follow you completely. What we were/are talking about is that the assumption a logging entry needs timestamp, log level and such is not appropriate. If you have legacy syslog style logging in mind it appears natural but for a lot of use cases it is not.
Could you provide example where it is not?
I just did a project in which I needed to understand a real-time parallel system that had 3 layers of abstractions. The code already had in place a log system based on log levels. If I opened the #debug level, I would get a ton of information, even though I wanted to focus on exactly one layer, or sometimes only one a certain type of leg entries. This is a common place scenario and it is time we can pick events based on their nature. The numbered layers come from languages where false=0, so letâs not use that as the standard we want to build on :).
Even if you could say that a timestamp is part of the logging domain it is not said if that timestamp needs to be part of the log object or the logger consuming this object. This question arises for every quality of a logging object. Even the logging level could be some behavioral quality that a logger matches to log levels. Contrary to this is logging thisContext which has to be done in the log object. I think the hard part is the way of distribution of log objects and filtering of them. While the former is being discussed with Beacon the latter is mostly ignored while being really important. Not having default qualities of a log object is good on one hand but on the other hand the filtering is much harder. In SystemLogger we didn't go far enough at first. The Log class contained level and such. That was the reason for me to split it into BasicLog consisting of timestamp and a message object and Log which contains the extra qualities.
My problem with such approach is that it forces me to create hierarchy of log events as subclasses of base log component.
But, you do not have to. Only if you want to distinguish between different log signals based on types. It is exactly the same type of problem that you have when you design the Exceptions in your system, or the domain-level Announcements in your system. Do you want to have fine grained types or use one single generic Exception? Do you want to have fine-grained or use plain Announcements? You can do it both ways, but it turns out you understand your system better if you use the types. Nevertheless, for prototyping purposes, you can certainly use quick logging.
Imaging that my application already provide hierarchy of events but they have no timestamps. How to log them? Should I use some WrapperSignal? Now imaging that application uses some library which provides events too. But this events are log entries themselves. What I will see in my logs? I will see mix of WrapperSignal's and normal events. It would be not easy to analize such log. That's why I want unified log entries. I would model it with single class LogEntry which nobody needs to subclass. It would contain logging domain information: timestamp, importance level, user message and whatever. And it would have content property to keep logging object. So our tools can rely on this structure to make it easy to work with logs. And when anybody will look at particular log he will be sure that logging object is inside "content" variables of each record
Signals are announcements. If you will have some events, those should be announcements. We could add to Announcements the ability to decorate an Announcement object (or at least a Signal one), we can tackle your scenario in a different way. Announcements is the unifying platform, not the logging. Logging is just an application of Announcements. But, the other point of view is that we should work to add instance variable filtering to Announcements, ideally in a way that does not pose performance penalty when you filter only by class. Once we do that we can have any combination you want. Also, just because you use Announcements does not put any limitation on the concrete domain objects you want to log. In any logging system you will have some wrapping object that will hold the concrete object. An Announcement is a great wrapping object exactly because it comes with the mechanism of transportation throughout the image, which is a technical prerequisite for logging anyway. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."