[Pharo-dev] Logging API discussion

stepharo stepharo at free.fr
Wed Apr 27 15:11:24 EDT 2016



Le 27/4/16 à 13:01, Denis Kudriashov a écrit :
> Hi Norbert
>
> 2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert at hartl.name 
> <mailto:norbert at hartl.name>>:
>
>     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.
>
>
> There is one problem with this approach when we split preparation and 
> emitting of log object. It will always produce garbage. If no logs 
> will have interest in myDomainObject or #warning-level messages 
> application will continue create log entries.
Denis I do not get what you mean with the sentence above.

> I think it is important to minimize cost of logging when nobody have 
> interest on particular event. If debug-level log is disabled then no 
> garbage should be created. If stack traces log is disabled then no 
> stack information should be retrieved anywhere.
> To achieve this we should create log entry instances only when we will 
> find any logs for them. It imposes restriction on possible API. At 
> point when we are ready to log something we should have all 
> information which can be part of filter. So if we want to filter logs 
> by domain objects and log-levels we need both parameters in one 
> message send. Then we can ask every registered log for interest about 
> both of them. And only when we will find any one we will create log 
> entry instance for them.
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160427/193f6986/attachment.html>


More information about the Pharo-dev mailing list