what I can tell you is that I do not like the API I did for extending
Log in SystemLogger.
I will try to read your long email.
Now I have the impression that wrapping an object in the log could be a
way to offer extensibility.
Le 26/4/16 à 15:26, Denis Kudriashov a écrit :
Hello.
I resumed discussion about SystemLogger and Beacon here
http://forum.world.st/What-the-state-of-unifying-Beacon-with-SystemLogger-td4890684.html.
I plan to unify both approaches by saving traditional terminology from
SystemLogger and cool features from Beacon.
Let's think about logging API to log any object in the system. Most
natural way is just send message #log to object itself:
anObject log
It would be nice replacement for Object>>logCr.
But when we log some information we usually want to log it with little
remark, importance level and (most important) timestamp. This
information is kind of standard for logging domain. But it requires
much more methods for logging API.
So we need extra information to put together with objects:
1. timestamp
2. user message
3. importance level (debug, info, error, etc.)
4. whatever (process hash, process name for example)
5. sometimes it can be needed to put in log something different than
object itself. (for example it can be just copy of object to not
change state of log entry during app lifetime)
Here is possible API based on Object extensions. It has drawbacks but
it is good to think about it too:
"it will put anObject in logs with default #info level"
anObject log
"it will put anObject in logs with default #info level and given
user message"
anObject logWith: 'something interesting was happened with anObject'
"inside block we can put any logging domain information from
application and also override content by specific representation"
anObject logBy: [:logEntry |
logEntry message: 'something interesting to be saved with
our object'
logEntry content: anotherObject] "here logs with interest
about anObject will receive logEntry with anotherObject instead of
anObject"
And similar for different kind of levels:
anObject logForDebug.
anObject logForDebugWith: 'some debug message'
anObject logForDebugBy: [:logEntry | ]
anObject logAsError.
anObject logAsError: 'object computation was wrong'
anObject logAsErrorBy: [:logEntry | ]
And most general:
anObject logAs: LogLevel warn
anObject logAs: LogLevel warn with: 'something interesting'
anObject logAs: LogLevel warn by: [:logEntry | ]
And in case of classic logging with strings only first expressions
would be used:
'some info message' log.
'some debug message' logForDebug
'some error message' logAsError
'some warn message' logAs: LogLevel warn
Problem with this approach: it pollutes Object with 12 extra methods
and it can be more. So maybe it is better to use current SystemLogger
API based on class Log:
Log info: anObject
Log info: anObject as: 'computation result' "as example"
Log info: anObject as: [:logEntry |
logEntry message: 'something interesting to be saved with our
object
logEntry content: anotherObject]
Log error: anObject
Log error: anObject as: 'computation was wrong''
Log error: anObject as: [:logEntry | ]
Comparing to original SystemLogger versions I separate user message
from object content. It makes possible to log any object with extra
user message.
But anyway it not feels very well IMHO. And it requires three methods
for each log level. Maybe we can put this methods into LogLevel itself:
Log info add: anObject
Log info add: anObject as: 'computation result'
Log info add: anObject as: [:logEntry |
logEntry message: 'something interesting to be saved with our
object
logEntry content: anotherObject]
Log error add: anObject
Log error add: anObject as: 'computation was wrong''
Log error add: anObject as: [:logEntry | ]
And we can make short version for default logging level (which can be
object specific):
Log add: anObject
Log add: anObject as: 'computation result'
Log add: anObject as: [:logEntry | ]
That's all. I hope we can produce best suitable API for object
logging. Then we can think how to adopt SystemLogger or Beacon for it.
Also think about this API in context that we can register specific
loggers for specific objects and specific importance level.
Best regards,
Denis
