Le 20/4/16 18:05, Denis Kudriashov a écrit :
Hi.
Thank's for answers.
2016-04-20 10:53 GMT+02:00 Norbert Hartl <[email protected]
<mailto:[email protected]>>:
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 happen.
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)
We picked Log because we wanted to have it short.
* 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).
It was the same as SystemAnnouncer.
It could be name Logger.
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.
LogDispatcher is coherent with Log.
If you change Log to be LogEntry then LogDispatcher could be named
LogEntryDispatcher.
* announcements LogAdded and LogRemoved in the core.
Why any Logger should announce every log entry?
Because you can build tools to reflect changes.
You do not want to use changed? We will remove changed from Pharo.
I think we not need special LoggerUI app. We can just inspect
SystemLogger instance to look at all recorded objects.
So we do not have the same dream and need. Not all tools should fit in
an inspector.
And in perspective of my suggestions it will mean that we just explore
particular ObjectLog. And we can extend GTInspector for this.
