harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: [classlib] logging from within our implementation
Date Wed, 31 May 2006 21:30:40 GMT
On 5/30/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> On Wednesday 31 May 2006 00:46 Ivan Volosyuk wrote:
> > > Any good behaving optimizing runtime would inline empty methods into
> > > nothing and therefore no performance impact would be made.
> >
> > Excelent! This is much better and simplier.
> >
> > public final class CLogger {
> >    public static void msg(Object... ) {..}
> > }
> >
> > Hmm, I see one drawback of this approach: arguments will still be
> > evaluated even if logger itself will be empty. So, some care needed to
> > maintain performance with such logger.
>
> If dead code elimination is done after inlining, then most likely code
> like
> string concatination and stuff like that would be deleted as well.


1 IMO ceki's next generation  bridging API has the signatures much closer to
being right than any other lightweight API i know of. one idea is that you
provide methods with extra parameters that are concatinated in the method
(if needed). for example:

debug(Object message)
debug(Object message, Object parameterOne)
debug(Object message, Object parameterOne, Object parameterTwo)
debug(Object message, Object parameterOne, Object parameterTwo, Object
parameterThree)

for a project such as harmony, it seems reasonable (to me) to restrict the
allowed logging calls to a limited number of parameters. developers should
remove any unreasonable calls before checking. so this solution might be a
good match.


2 for harmony, i'd consider not using a logging class at all. add private do
nothing template methods to any class that is likely to need logging. if a
developer needs to turn on logging for a class they run an enhancer to wire
those calls to an appropriate logging architecture.

for example:

public class DoSomethingCool {

   public void whatever(What what, Ever ever) {
      debug("This is really complex!", what, ever);
      ...
   }

   private debug(Object message) {}
   private debug(Object message, Object parameterOne) {}
   private debug(Object message, Object parameterOne, Object parameterTwo)
{}
   private debug(Object message, Object parameterOne, Object parameterTwo,
Object parameterThree) {}
}

- robert

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message