Denis, Try to look at it this way: by using objects (events, signals, announcements, whatever) and just generating them on the spot and sending them off somewhere, you have everything you need, without imposing any restrictions.
If you want to use log/severity levels and/or categories and/or tags, you can do that. But I don't want to. Your objects will contain that info and you will be able to filter on it. I take a very extreme standpoint here: there should be no requirements at all. Not for the kinds of objects that one can use, nor where/how they are sent to/handled. I even do not want a specific kind of timestamp imposed. DateAndTime is way too expensive and has either too much or not enough granularity (we have no nanosecond clock). There could be some convention (a trait maybe) that says #timestamp returns a Magnitude that can be used for that purpose. If you want a small system (builder) that makes it easier to construct and signal log events, then that could be provided, but is will always be quite specific to one person's taste. Making log events subclasses of Announcement and using an Announcer instance local to a subsystem is one easy implementation choice, but not necessarily the only one. One concrete (but not perfect) implementation of my ideas can be found in the package 'Zinc-HTTP-Logging' in your image. Sven > On 26 Apr 2016, at 17:31, Denis Kudriashov <dionisi...@gmail.com> wrote: > > > 2016-04-26 17:28 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>: > 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. > > And I forgot mention that my proposed API is not prevent object filtering. > All information is here. So it can be implemented. And it also can be > implemented by announcements. > But here I just want to discuss API.
