Hi, >From my point of view, the problem comes from the following forces: - the class side wants to be a log - the instance side wants to be a log entry
The better solution here would be to have two classes: Log and LogEntry. This is particularly important in the light of extensibility when people will want to define their own log entries. Cheers, Doru On Sun, Feb 23, 2014 at 1:48 AM, <[email protected]> wrote: > Tudor Girba wrote: > > Excellent, Stef! > > I reviewed a bit the code: > - The name log denotes the recording of multiple events. However, the Log > class models only one event, not many. Thus, a more suitable name would be > LogEvent. Or maybe LogEntry (like in StarTrek :)) > > Except Log as only accessed as a class, not as instances. In days of old, > sailing ships had a single Log book kept in the captain's room. Also > Transcript is not called TranscriptEvent. So for me the semantics of Log > are fine. > cheers -ben > > > - Similarly, SystemLogger>>logs should be something like > logEvents/logEvents. > > I like it a log that LogEvents are full objects because we can subclass > them with specific semantics. This is particularly important if we want to > build tools for custom applications. The first application I have in mind > is Zinc. > > Zinc already comes with a logging mechanism that treats LogEvents as > objects, but they are all of the same type, so in the end, if you want to > track the events for request/response you have to reverse engineer the > text. These semantics could be preserved. > > From what I see, the main difference between the Zinc log system and the > SystemLogger is that the latter has a dispatcher that can dispatch to > multiple loggers. Is there anything else that is different? I think it > would be cool to merge the two. > > Doru > > > 2014-02-22 13:24 GMT+01:00 Pharo4Stef <[email protected]>: > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"
