A more pure design #9
Conversation
Codecov Report
@@ Coverage Diff @@
## master #9 +/- ##
===========================================
- Coverage 100% 80.32% -19.68%
===========================================
Files 3 7 +4
Lines 19 61 +42
===========================================
+ Hits 19 49 +30
- Misses 0 12 +12
Continue to review full report at Codecov.
|
|
Added Transforming logger, And a discussion of what compositional logging is. |
|
@c42f this is the outcome of that discussion we had a few (6?) months ago. |
There was a problem hiding this comment.
This is an interesting approach. I wasn't quite sure that filtering and transformation are orthogonal, but the benefit of deciding that they are is that it's simple: they can be defined with a single function each.
For now I've just added some high level comments without looking very carefully at the implementation.
I really should finish my (mostly equivalent-in-spirit) version of the same thing so we can compare notes better. My prototype had a few differences, perhaps the most obvious one being that filters / transformers were not AbstractLoggers, but rather a separate filter type. This meant filters could be composed together and instantiated without reference to the underlying sink. This is helpful because it allows for things like a function filterlogs(SomeFilter(args...)) do ... rather than the pattern with_logger(SomeWrapper(current_logger(), args...)) do ... which kind of gets annoying.
|
By the way, I'm reviewing this with the thought that some successor or closely related sibling of this code will end up in I think we can (carefully) change core logging to make it easier to write backends. The only thing which is really set in stone at this point is the syntax of the logging macros themselves. Changes to those would be julia-2.0 material. |
This PR solves all the philosphiocal issues I had with the earlier version.
Other than the basically indicidental improvement to UX from the switch to giving the filter named tuples, it doesn;t change much in the capacity of LoggingExtras.
FileLogger is now a pure sink, so accepts 100% of everything given to it. (#8)
to allow it to be not a problem we introduced more levels of filter,
MinLevelLogger,EarlyFilteredLogger(#6) andActiveFilteredLogger.The
ActiveFilteredLoggeris a revised version of the previousFilteredLogger.In the new version (and in the
EarlyFilteredLogger) rather than passing to the user specified functions like 7 different arguments, we pass them a named tuple. (solving #7).One thing to note is that compositional loggers,
like the filtered loggers and the
DemuxLogger,to have to make sure to check the
shouldlogandmin_enabled_levelof there children.Which is a bit ugly.
But these are almost all the composable loggers that I can imagine.
Except for the
TransformingLogger(#5).All filtering you might ever want to do can be configured using the 3 filtering loggers
and a filtering function or closure.
As such no-one should ever have to write a composable logger again,
except for writing pure sinks (like the
FileLogger),and writing pure sinks doesn't run into that uglyness of having to check your children.
So I think that that little big of uglyness is fine.