You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #10 we were discussing how to use the modules the "right" way. I want to start a discussion on this topic and want to make a suggestion.
What is the purpose of the modules?
I don't know what the initial purpose of the modules was, but I think it was mainly to distinguish between logging locations.
This means to have the possibility to display the location of the code from where the log is published. For example:
Class A logs with module A and Class B with module B and so on.
I don't think that this behavior is necessary or valuable for a Singleton Logger and if it is needed a new Logger can be created.
If this behavior is wanted we should make the Logger-Singleton more of a "factory" for logger than the "actual thing" to solve the modules problems. This is just my opinion please discuss!
Suggestion
I want to convert modules more towards an "Appender" approach.
Which means the Logger holds modules which are all called if something is logged.
This means you can have a module for a file logging with custom logging and a module for the console and so on.
This would result in a change of the API and how the logger is used.
Any feedback is welcome!
The text was updated successfully, but these errors were encountered:
Another thing I noticed:
Currently, it is not possible to extend the modules.
For example if I want a module to write to a component on screen or send the data else where it is not possible.
I think I would be good to make the Modules more configurable. @akien-mga What are your thoughts on that?
In #10 we were discussing how to use the modules the "right" way. I want to start a discussion on this topic and want to make a suggestion.
What is the purpose of the modules?
I don't know what the initial purpose of the modules was, but I think it was mainly to distinguish between logging locations.
This means to have the possibility to display the location of the code from where the log is published.
For example:
Class A logs with module A and Class B with module B and so on.
But @akien-mga may have more insight.
I don't think that this behavior is necessary or valuable for a Singleton Logger and if it is needed a new Logger can be created.
If this behavior is wanted we should make the Logger-Singleton more of a "factory" for logger than the "actual thing" to solve the modules problems.
This is just my opinion please discuss!
Suggestion
I want to convert modules more towards an "Appender" approach.
Which means the Logger holds modules which are all called if something is logged.
This means you can have a module for a file logging with custom logging and a module for the console and so on.
This would result in a change of the API and how the logger is used.
Any feedback is welcome!
The text was updated successfully, but these errors were encountered: