I must confess I cannot follow you completely. What we were/are
talking about is that the assumption a logging entry needs timestamp,
log level and such is not appropriate. If you have legacy syslog style
logging in mind it appears natural but for a lot of use cases it is
not. Even if you could say that a timestamp is part of the logging
domain it is not said if that timestamp needs to be part of the log
object or the logger consuming this object. This question arises for
every quality of a logging object. Even the logging level could be
some behavioral quality that a logger matches to log levels. Contrary
to this is logging thisContext which has to be done in the log object.
I think the hard part is the way of distribution of log objects and
filtering of them. While the former is being discussed with Beacon the
latter is mostly ignored while being really important. Not having
default qualities of a log object is good on one hand but on the other
hand the filtering is much harder.
In SystemLogger we didn't go far enough at first. The Log class
contained level and such. That was the reason for me to split it into
BasicLog consisting of timestamp and a message object and Log which
contains the extra qualities. Nowadays I think you should be able to
use any object as log object. The provided classes are just helpers. A
composed object that has timestamp, level and a message object is a
good utility but not a requirement. We need to support all of these.
And so I would object against putting a lot of protocol in the Object
class. In SystemLogger you have
Object>>#asLog
^ self class newLog message: self
Object class>>#newLog
^ self logClass new
Object class>>#logClass
"Hook supporting the redefinition by object of their associated log.
When using myObject asLog emit, the logClass will be used and myObject
will be passed as message argument."
^ Log
So assuming the Log class would not contain log levels but SysLog
would do you could easily override #logClass in your domain object and
use it this way
MyDomainClass class>>#logClass
^ SysLog
myDomainObject asLog
warning;
emit
This way we do not need to pollute Object with a lot of methods that
are tight to one use case. The call to #warning could be something
else that only depends on the Log class you want to use.
So to me the discussion about Log classes is not very helpful. We can
have dedicated log classes like the stack capturing one but also one
that is composed of the message object and certain qualities. If you
would have a WrappedSyslogSignal you can have a log object that is
composed and syslog aware by providing log levels. Again I think the
hard part is to have flexible logging and still be able to filter it.
I would like to be able to attach a handful of loggers and be sure the
loggers get the right set of log objects they are interested in.
Hi norbert
I agree.
I have the impression that in SystemLogger I would change message: into
object: in Log and remove all the extension API I tried to design.
This way people can just pass the object they want if they want still to
have the object wrapped into a Log instances.
I think that Log instances and subclasses would be nice to have specific
behavior (like menu actions when we want to manipulate logs).
For example, I would like to have a tool looging all the methods that I
did not define during a prototype session and after I can click on them
and say "define skeleton"
and boum I get a skeleton for all the methods inside their respective
classes.
Stef
