Implement generalized event and log interfaces #272
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ref: #271
log
package containing generalized internal (Event
) and external (Logger
) interfacesevent
)leveled_logger
)This PR is more to get feedback on how you feel about this type of implementation. I feel I made it pretty flexible. The idea is, when the client is instantiated, the config would have a
Logger
property as it does already. I made aLogger
interface for this so anyone can make their ownLogger
. TheLogger
only receivesEvent
s and handles them as desired.The simplest implementation could have a NOOP style implementation of
Log
that would never log anything. A more complex version could introspect the event and do it's own filtering and formatting as desired.Event
is primarily for internal implementation. Types (which need to log something) can have a copy of theLogger
passed to them when they are instantiated. After that they can easily call theLogger
with anEvent
they created.I added a few basic
Event
types to do some basic event logging and error logging.Below is an example usage of the
event
andleveled_logger
subpackages: