Am 16.06.2014 um 09:15 schrieb Sven Van Caekenberghe <sven@stfx.eu>:

On 16 Jun 2014, at 08:25, stepharo <stepharo@free.fr> wrote:

Hi sven

Objects are the way to go.

Yes !

Will this compatible be with SystemLogger? I mean could not you use SystemLogger?

I hope that SystemLogger can work with a subsystem that generates a stream of log objects, without requiring them to be subclasses of something. If so, then it will be compatible (just connect the announcer to where you want to sent the objects to). If not, then I don't understand how SystemLogger can be a pure object log.

I said this before (and I miss this in the SystemLogger documentation, and even in the Beacon description): show real object based logging from the beginning, not degenerate string logging.

In the case of SystemLogger, the class BasicLog already contains a message, why ? The API is also still mainly expressed with strings. (BTW, there should not be a messageText in exception, for example, being an instance of ZeroDivide or KeyNotFound with a key says it all).

This is somethings that bugged me for a long time. The message instVar in BasicLog has probably a misleading name. The message is suppsoed to contain any object not just a string. BasicLog and Log are not supposed to be subclassed if you haven�t special needs. BasicLog has two instVars: a timestamp and a message object. It acts as a decorator for any object you like to log. Therefor we have

Object>>#asLog

^ self class newLog message: self�