[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] Code update and class variables
From: |
Paolo Bonzini |
Subject: |
Re: [Help-smalltalk] Code update and class variables |
Date: |
Tue, 07 Sep 2010 12:22:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.0.5 |
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
- [Help-smalltalk] Code update and class variables, Holger Hans Peter Freyther, 2010/09/06
- Re: [Help-smalltalk] Code update and class variables, Paolo Bonzini, 2010/09/06
- Re: [Help-smalltalk] Code update and class variables, Holger Hans Peter Freyther, 2010/09/06
- Re: [Help-smalltalk] Code update and class variables, Paolo Bonzini, 2010/09/06
- Re: [Help-smalltalk] Code update and class variables, Holger Hans Peter Freyther, 2010/09/06
- Re: [Help-smalltalk] Code update and class variables, Paolo Bonzini, 2010/09/06
- Re: [Help-smalltalk] Code update and class variables, Holger Hans Peter Freyther, 2010/09/06
- Re: [Help-smalltalk] Code update and class variables, Paolo Bonzini, 2010/09/07
- Re: [Help-smalltalk] Code update and class variables, Holger Hans Peter Freyther, 2010/09/07
- Re: [Help-smalltalk] Code update and class variables,
Paolo Bonzini <=