Re: [Help-smalltalk] Code update and class variables

[Paolo Bonzini]

On 09/07/2010 10:53 AM, Holger Hans Peter Freyther wrote:
> On 09/07/2010 04:23 PM, Paolo Bonzini wrote:
>
>
> > LogTarget class methods can be used to set a default logging target
> > and, as you mentioned, you could have also a per-process LogTarget.
> >
> > You can add a LogMultiplexer class to emulate
> > log_add_target/log_del_target.  It can be just an internal detail.
> >
> > How does this look?
>
> Thanks for taking the time, the LogFilter hierachy is a nice idea. One reason
> to have the dedicated 'LogArea' class is from a configuration point of view.
>
> A user does not want to reconfigure the LogTarget (and the filters applied on
> it) but he wants to see the SCCP messages. So currently on the telnet
> interface I do something like:
>
>         logging SCCP enabled.
>
> With the filtering I would have to add an allow filter, or remove from the
> target which is certainly possible but a bit of a hassle. On the other hand by
> having a nice chain of filters one can do a lot more.

Yeah, maybe the LogFilter hierarchy sacrifices usability too much.  It's 
nice to be able to modify the filter.  Maybe you can make instead a 
hierarchy with LogFilter on the side instead of under LogTarget:

    LogEntry
    LogPolicy (abstract)
        LogFilter (implements a dynamically-changeable filter)
    LogTarget
        LogFile
        LogSyslog
        LogMultiplexer

Then every LogTarget has a LogPolicy and you can send messages like

   LogTarget>>policy
       ^policy ifNil: [policy := self defaultPolicy]

   LogTarget>>defaultPolicy
       ^LogFilter new
           minimumLevel: LogEntry error;
           yourself

   LogTarget default policy
       disable: #SCCP.
   LogTarget processDefault policy
       enable: #SCCP minimumLevel: LogEntry all.

Then LogTarget's logging method would have to create LogEntry, test it 
against its LogFilter, and if successful pass it to the abstract method.

Another idea: LogPolicies could make a chain and, if the object 
specifies neither enable nor disable, it could delegate to the next 
policy.  So for example the process-default policy could delegate to the 
global policy.  This delegation could be implemented in the abstract class.

    LogPolicy>>accept: anEntry
        (self shouldAccept: anEntry) ifTrue: [^true].
        (self shouldRejept: anEntry) ifTrue: [^false].
        ^self next isNil
            ifTrue: [true]
            ifFalse: [self next accept: anEntry]

    LogPolicy>>shouldAccept: anEntry
         self subclassResponsibility

    LogPolicy>>shouldReject: anEntry
         self subclassResponsibility

    LogTarget>>defaultPolicy
        | policy |
        policy := LogFilter new
           minimumLevel: LogEntry error;
           yourself.

        self == self class default
            ifFalse: [policy next: self class default policy].
        ^policy


(BTW, LogMultiplexer can have its own policy, which is combined 
(logically by an AND) with its targets' policies).

Does this look nicer?

Paolo