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

stepharo stepharo at free.fr
Thu Apr 21 09:02:32 EDT 2016

> 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.


>    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

More information about the Pharo-dev mailing list