[ANN] Continue working in SimpleLogger

Thanks you very much Mariano!

Sound very interesting.

I only read the mail by now (not time, as usual) but as soon as I have
a bit of free time, will try and make my comments.

Of course, not problem in that you commit on the SimpleLogger repo, I
added you as Developer.

Cheers.
Germán.


2010/10/20 Mariano Martinez Peck <[hidden email]>:

> Hi guys (German).
>
> Today I needed to add some real log to something I am developing and I found
> that SimpleLogger missed those functionalities I was needing. So...I
> implemented them. It is 3 hours effort, so don't expect too much. But I just
> wanted to shared with you in case you need it.
>
> 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...)
>
> I did these changes today morning so I didn't have time to write tests nor
> class comments. However, I wrote some class side example methods in
> SimpleLogger.
>
> Finally, for my own projects I want:
> - to use a FixedFileName (very similar to the way PharoDebug.log is used).
> - to only do "self log:" in my classes.
>
> The solution I did is that somewhere (maybe in a class of your project or
> maybe in a special class that holds this) in a class side variable I hold a
> Singleton with the Logger. So that you can always do for example:
> MyAppLogger logger log: 'zaraza'.
>
> And finally, I implemented Object >> log:   (with category *MyAppPackage)
>
> log: anObject
>       MyAppLogger logger log: anObject.
>
> With this, anywhere in the classes of my app I can do:   self log:
> 'something'.
>
> The code is temporally commited in http://www.squeaksource.com/Marea
>
> German: if you think I should commit directly to SimpleLogger repo, just let
> me know. In addition, be completely free to change it as you want and commit
> it there too.
>
> Cheers
>
> mariano
>

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.

IMHO, it should be a fork: SomewhatSimpleOnItsWayToComplicatedLogging :)

--
Yanni


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

why don;t you look look at toothpick?

On Oct 21, 2010, at 3:23 AM, Yanni Chiu 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.
>
> IMHO, it should be a fork: SomewhatSimpleOnItsWayToComplicatedLogging :)
>
> --
> Yanni
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users