On 10 Apr 2013, at 10:58, stephane ducasse <stephane.duca...@free.fr> wrote:
>> formatting especially in emitting the current timestamp and the >> class>>method automatically >> >> I feel Toothpick can be extended to the above and with clear separation of >> lean classes it can serve the enterprise class of apps well. >> >> While SimpleLog, seems equally good, but I have not used, seems to offer one >> more error level and similar appenders capability. >> >> **************************** >> One observation I have is for all logger libraries to adopt same api for >> logging error viz: >> >> logger level: #warn message: 'This warning' . ( category is #default and >> most often usable) >> logger category:#perf level: #warn message: 'Below threshold of 100 trans >> per second' . >> >> convenience messages thereafter also be the same api viz: >> logger info: 'This info' . logger warn: 'This warning' . logger error: 'this >> exception' et als.. >> >> It will make it easier to switch logging framework if so required in future. > > good idea. Yes, I think we should first focus on the API for the code doing the logging. It would be very cool to have one API and possibly different logging destination, with different capabilities. I already mentioned the block trick with the optional error handling. Another point is, should we not allow for arbitrary objects to be logged, so that afterwards there is an option to inspect them (this might be dangerous wrt destructive modifications and GC) - does Gemstone not have an 'Object Log' ? Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
