On Thu, Oct 21, 2010 at 3:22 AM, Yanni Chiu <yanni@rogers.com> wrote:

On 20/10/10 9:36 AM, Mariano Martinez Peck wrote:

...

What I did basically is to define SimpleLogger like the public API. But then, this class delegates to a LoggerStrategy. I created the following implementations: TranscriptLoggerStrategy, NullLoggerStrategy, FileLoggerStrategy and FixesFileNameLoggerStrategy. In addition, I created a superclass for them, marking the API with SimpleLogger. This class is LoggerStrategy.

So, now you can:

- Enable and disable easily the logging (thanks to NullLoggerStrategy). - Change on runtime WHERE or HOW to log (just change the strategy). - Be able to write into a File, a Transcript, a FixedFileName, or nothing. - Extend to you own strategy (FileAppendLoggerStrategy?? SocketLoggerStrategy? etc...)

My 2cents. I've not used or looked at SimpleLogger, but recall that it was a single class, plus a metacello config class.

The new functionality sounds very useful, but is it still simple. It sounds like it was simple to add extra features - maybe because SimpleLogger was simple. Will the next person who comes along find a similarly simple implementation that can be easily adapted to specific needs.

A hierarchy of strategy classes no longer sounds simple. What if I don't need all the different strategies loaded, will the configuration then allow multiple build targets for various individual or groups of strategies. Starting to sound complicated.

Yes, that's true. However, take a look at the code, and I promisde that in no more than 10 minutes you get the idea how to use it. There are 5 classes, with an average of 5 methods each.

IMHO, it should be a fork: SomewhatSimpleOnItsWayToComplicatedLogging :)

heheheh

-- Yanni

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project