[Pharo-dev] What the state of unifying Beacon with SystemLogger?

Denis Kudriashov dionisiydk at gmail.com
Wed Apr 20 12:05:36 EDT 2016


Thank's for answers.

2016-04-20 10:53 GMT+02:00 Norbert Hartl <norbert at hartl.name>:

> Agreed. As I said above. If you take to point of view from legacy logging
> tool Beacon is not a big help. But the ideas in it are good and should be
> integrated somewhere. If you are talking about legacy tooling it might ok
> to use the terms logging as well, no? I personally like the work Beacon but
> in my opinion it is  wrong for this purpose. A beacon sends a uniform
> signal in order to be discovered. The Beacon code sends signals to a
> beacon. And I can register at the beacon in which signals I'm interested
> in. Feels wrong to me.

Your words are reasonable. Interesting what Tudor think about it?

There are few things which I not like in SystemLogger (which not means that
everything is good with Beacon):

   - name Log to represent records of the underlying "physical log".

IMHO Log means exactly end logging backend like text file, syslog or
external database. Log is the place where we can explore (read) what was
And now these backends are represented by subclasses of Logger:
StdoutStreamLogger, SysLogSender. I would call them StdoutLog, SysLog.
But with such change we need to call log entry differently. It can be
LogRecord or LogEntry. I not understand what was the problem with such
names? (there was some explanation why Log was chosen for this)

   - name SystemLogger for collection based log.

SystemLogger makes me think that it is singleton which is used by system
and I should not use it for my own application.
I would call it like ObjectLog or NativeLog (following my first sentence
about Log).
Also it is intercepted with SysLog name and I guess that's why it was
called SysLogSender and not SysLogLogger.

   - name LogDispatcher.

Here same problem as Log. What means physical logs dispatching? I know it
is introduced around Log as log entry. But it is not intuitive for me (same
as Log).
In context of Log as real log (FileLog, SysLog) I would call this
dispatcher as Logger with same responsibility to register new events in all
registered logs.

   - announcements LogAdded and LogRemoved in the core.

Why any Logger should announce every log entry?
I think we not need special LoggerUI app. We can just inspect SystemLogger
instance to look at all recorded objects. And in perspective of my
suggestions it will mean that we just explore particular ObjectLog. And we
can extend GTInspector for this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160420/43403ff5/attachment.html>

More information about the Pharo-dev mailing list