"Another point is, should we not allow for arbitrary objects to be logged,"

The core framework should not be doing this, allow extension for anyone
interested to do so at their risk and understanding.

I will first attempt to get Toothpick to basic expectations, to then take
up additional extensions.



On Wed, Apr 10, 2013 at 2:42 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:

>
> On 10 Apr 2013, at 10:58, stephane ducasse <stephane.duca...@free.fr>
> wrote:
>
> >> formatting especially in emitting the current timestamp and the
> class>>method automatically
> >>
> >> I feel Toothpick can be extended to the above and with clear separation
> of lean classes it can serve the enterprise class of apps well.
> >>
> >> While SimpleLog, seems equally good, but I have not used, seems to
> offer one more error level and similar appenders capability.
> >>
> >> ****************************
> >> One observation I have is for all logger libraries to adopt same api
> for logging error viz:
> >>
> >> logger level: #warn message: 'This warning' .  ( category is #default
> and most often usable)
> >> logger category:#perf level: #warn message: 'Below threshold of 100
> trans per second' .
> >>
> >> convenience messages thereafter also be the same api viz:
> >> logger info: 'This info' . logger warn: 'This warning' . logger error:
> 'this exception'  et als..
> >>
> >> It will make it easier to switch logging framework if so required in
> future.
> >
> > good idea.
>
> Yes, I think we should first focus on the API for the code doing the
> logging. It would be very cool to have one API and possibly different
> logging destination, with different capabilities.
>
> I already mentioned the block trick with the optional error handling.
> Another point is, should we not allow for arbitrary objects to be logged,
> so that afterwards there is an option to inspect them (this might be
> dangerous wrt destructive modifications and GC) - does Gemstone not have an
> 'Object Log' ?
>
> Sven
>
>
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
>
>
>
>
>
>

Reply via email to