You are considering Log as a noun, but it can also be used as a verb.
defn "13. to enter in a log; keep a record of; e.g. to log a day's events." [1]
Stef said: "Remember that you want to have them short especially for
the main one. This is why in SystemLogger
we have Log instead of what it is LogObject"
from which I understood that Log was the client interface, to be used
like Transcript.
Yes
I think this is a good idea. It would create the
LogEntry
[1] http://www.dictionary.com/browse/log
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)
Considering a "log" being the final resting point of the logged
objects, that is the external disk text file or database, then within
Pharo we don't have logs, only processes that write to the external
logs, so Logger seems appropriate. This is except for an in memory
log, which for backend might need both MemoryLogger and
MemoryObjectLog.
Log would create and send theLogEntry to SystemLogger
which forwards theLogEntry to other registered XXXLogger backend.
Yes this is exactly that
Log -> Dispatcher -> Loggers
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 guess your application would make use SystemLogger via Log at the
front end, and registering backends with SystemLogger.
I would call it like ObjectLog or NativeLog (following my first sentence
about Log).
NativeLog doesn't seems right. ObjectLog might be suitable for an
in-memory backend, like above I mention MemoryObjectLog.
Also it is intercepted with SysLog name and I guess that's why it was called
SysLogSender and not SysLogLogger.
name LogDispatcher.
LogDispatcher is okay, but I'm not sure of convention to be associate
the "doer" with the "target" rather than the "item", where
doer=Dispatcher; item=LogEntry; target=final-backend-log; A little
it sounds like its dispatching a whole log rather than one log entry.
Maybe should be LogEntryDispatcher(??) or... SystemLogger as the
marshalling point to forward to other XXXLoggers.
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).
I don't think Log should be a log entry. It should be the user
interface that creates and sends LogEntries via some XXXLogger.
Here since we did not want to have two class
Log for the creation API
LogEntry/LogObject for representing the entry
we choose to keep Log even if Log was not name LogEntry
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.
GTInspector would need good live updating, filtering, clearing,
scrolling to keep cursor position as new entries arrive.
cheers -ben
