Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

A standard logging API 21 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'm not sure why, but I think the API lacks a certain elegance.

    Personally I'd have done the name'ology differently (although tbh I'm not sure what I'd have used instead).
    • Upon re-reading I think two things I'm not a fan of are the "Any" suffix, and the use of package-named class-level storage.

      What if I want to make an logger for a single object...
      • As far as the package-named class-level storage: the "use Log::Any qw($log)" syntax is just a convenient shorthand that, imho, will be good enough for some modules. If you are uncomfortable with this, you can use the more standard syntax

                my $log = Log::Any->get_logger(category => '...');

        and you would use this to create a lexically scoped logger or a logger contained in an object.

        As far as the "Any" name - I agree, it isn't ideal, but I haven't been able to think of a better
        • I don't mean for $log, I mean for "category => '...'.

          That implies you are keeping inside Log::Any a hash of some sort with the class as the key and an object or log class as the value. That's what I meant by the class-level storage.

          As for ::Any, I notice that Log::Abstract seems to be unused at the moment, if you do a CPAN search for "Abstract" and have a read through some of the modules there, there is a precent for this general type of thing.
          • > As for ::Any, I notice that Log::Abstract seems to be unused at the moment, if you do a
            > CPAN search for "Abstract" and have a read through some of the modules there, there is a
            > precent for this general type of thing.

            Thanks, I like that name much better! "Any" has always seemed rather...indecisive. I'm going to retroactively change this in the journal entry.

            > I don't mean for $log, I mean for "category => '...'.
            >
            > That implies you are keeping inside Log::Any a hash of some sort with
  • Generally, I think this is a good idea, but I have some nits to pick.

    First, the set_logger() method is not actually setting a logger at all, which is confusing. It's setting a callback that returns a logger, so maybe it should be set_logger_factory() or something like that. This is particularly problematic since there's a get_logger() method, which doesn't return the thing passed to set_logger()!

    I'm not sure that passing in a sub ref is the best API either. My gut feeling is that "the average programmer" is
    • I got the impression that all CPAN modules should use the logging interface, but not set any logger themselves.
      So the only place the logger would be set would be in your 'top level' application, or framework (catalyst, jifty, etc).
      • That's exactly right. Since the setting of Log::Abstract is (by design) global across the application, it would be considered bad behavior for an arbitrary CPAN module to muck with it, in the same way it would be bad behavior to unset $^W, or clear @ARGV, or read from STDIN - unless that was part of the proscribed behavior of the module.
    • > First, the set_logger() method is not actually setting a logger at all, which is
      > confusing. It's setting a callback that returns a logger, so maybe it should be
      > set_logger_factory() or something like that. This is particularly problematic since
      > there's a get_logger() method, which doesn't return the thing passed to set_logger()!

      You're right, set_logger() should be renamed, though I'm not sure I can bear to use "factory". :)

      >
      > I'm not sure that passing in a sub ref is the best API eith

      • You’re right, set_logger() should be renamed, though I’m not sure I can bear to use “factory”. :)

        The name you are looking for is register_logger.

  • I'm not really a fan of the ::Any namespace - JSON::Any being particularly bad as all the JSON modules have different quirks and JSON::XS is clearly way above the rest. Why couldn't we just pick one logging module as good enough and call it best practice?
    • I believe the optimum number of CPAN modules for any single topic is seven :)

      There's also a Log::Tiny module potentially coming (not from me, I just got the email asking to review it, and it's being munged to bring it up to ::Tiny spec at the moment).

      On a side note of trivia, this is the second time I've had a proposed Log::Tiny one, in the end the first person decided he wasn't willing to cripple it enough to meet the criteria, so it ended up being called something else.
    • This project arose from trying to pick a logging scheme for Mason. I decided pretty quickly to standardize on log4perl, until I talked to Dave, who understandably demanded consideration for Log::Dispatch users.

      I figure if a single little project can't even decide on a best logging module, it'll be damned near impossible to get the whole community to agree. :)
  • $log->debug("a debug message") if $log->is_debug();

    I'm not sure why you want the "if" clause. I'd prefer to have the debug method just do nothing unless debugging is enabled. If you're trying to avoid a method call, you'd want:

    $log->debug("a debug message") if $is_debug;

    though personally I'd just prefer:

    $log->debug("a debug message");

    • You're right, that was a poorly chosen example. Yes, $log->debug() won't do anything unless debugging was enabled. Here's a more appropriate use of the conditional:

              $log->debug("current args: " . Dumper(\@_))
                    if $log->is_debug();

      The idea is to use the conditional when you don't want to compute the arguments (in this case, Dumper()) unnecessarily.
      • I seem to recall that one of the other logging modules (I forget which) uses a sub for that.

        $log->debug(sub {"current args: " . Dumper(\@_)});

  • Hi Jonathan, you're addressing something really important here.

    It is really unfortunate that important CPAN modules like LWP or Rose::DB don't have usable logging mechanisms in place. Once you're used to category-based logging it's hard to go back to these home-grown and less convenient solutions.

    I think it's a great idea to promote standardized logging on CPAN and letting the user choose the actual implementation will definitely help to make strides towards that goal.

    By the way, I don't agree that

    • > By the way, I don't agree that "For small modules that want to
      > minimize dependencies, depending on Log4perl (for example) is a
      > non-starter." The Log4perl core doesn't have dependencies other
      > than perl's core modules.

      Fair enough.

      >
      > One thing missing from your proposal is Log4perl's :easy mode
      > [sourceforge.net]. If you think about it, getting a logger and
      > calling its method is a lot of typing, given that you just want
      > to log something. That's why in Log4perl you can use
      >
      • > So this creates a logger for you with the category set to the current
        > package, similar to easy mode. The syntax is pretty minimal.

        Ah, gotcha. So you would call

                $log->debug(...)

        instead of

                DEBUG "..."

        which is probably acceptable in terms of additional key strokes
        (although it might throw off novices).

        > The problem I have with the DEBUG etc keywords is that they promote
        >inefficient behavior. e.g.
        >
        > DEBUG "Current arguments: "

        • Assertions were going to make that possible in 5.10.

          Unfortunately they were recently removed from bleadperl. :-(

  • I just stumbled across this thread, and I must admit - it's exactly what I was thinking about for the past few weeks... I need logging, but don't want to tie my users to un-wanted dependencies. Better yet, is that the users could *choose* their preferred logging deps.

    Is there any code out in the wild yet? I may have a few CPAN-bound uses for it!
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.