Re: [log4perl-devel] Re: logdie / logcroak

[Erik W. S. <er...@se...>]

Kevin Goess wrote:

> I just took a shot at some of these:
>
> 1) inc_level, dec_level: I didn't really like "more_logging", though 
> you could talk me out of it, and we should document which direction 
> "increment" goes.  Boundary conditions are handled, if you call 
> inc_level(999) you just get the highest level in %Level::PRIORITY.

So the more I think about it, the less I like exposing the user to the 
concept that there's some integer value that corresponds to a Level --- 
especially when we get into the realm of subclassing and having users 
define their own Levels and inserting them in the order. inc_level and 
dec_level kinda do that, as what we want is inc_level to correspond to 
more logging (as "more" implies "bigger numbers"), but it's gonna get 
messy in the code. more_logging() / less_logging() allow us to abstract 
HOW we do the order, and lets the user do what he or she wants: get more 
or less logigng. :)

Besides, with more_logging and less_logging, we don't need to document 
which way "increment" goes. :)

-e

>
>
> 2) custom error levels: I changed the Logger: sub fatal{..}, sub 
> error{..}, etc. to autogenerated code based on the contents of 
> %Level::PRIORITY.  So the user can generate custom levels if they a 
> BEGIN block before calling 'use Log4perl'
>
>   #create a custom level "LITEWARN"
>   BEGIN {
>   package Log::Log4perl::Level;
>   our %PRIORITY = (
>     "FATAL" => 0,
>     "ERROR" => 3,
>     "WARN"  => 4,
>     "LITEWARN"  => 5,
>     "INFO"  => 6,
>     "DEBUG" => 7,
>   );
>   }
>
> This seems kind of hacky to me (if simple and effective), I sort of 
> feel we should be subclassing Level and doing some stricter OO stuff, 
> though I don't see any particular problems with doing it this way.  If 
> you guys don't like it, I'll back the changes out of CVS.
>
> The caveats are that if the users make sub fatal{..} go away and don't 
> replace it, then they break the logdie() stuff.  And their new level 
> names have to be valid perl subroutine names.
>
> It's all in CVS, see the new unit test 025CustLevels.t .  Any comments?
>
>
> Erik W. Selberg wrote:
>
>>>
>>> > So here's what would make me happy, which is similar. :)
>>> >
>>> > inc_level($levels)
>>> > dec_level($levels)
>>>
>>> Ja, way better!
>>>
>>> > we assume we're starting off at Level 0 (OFF / FATAL :),
>>> > $log->inc_level(3) puts us up three levels. If those levels happen 
>>> to be
>>> > ERROR, WARN, and INFO, then we're at INFO. If some user decides they
>>> > need CRITICAL and ALERT (say legacy syslog support) and put them in,
>>> > then inc_level(3) just get's 'em to ERROR. Make sense?
>>>
>>> Yeah, but the other way.  All the log4j docs say FATAL is *high* and 
>>> DEBUG is *low*, (DEBUG < INFO < WARN < ERROR < FATAL) so from INFO 
>>> $log->inc_level(2) would give you ERROR.  When adding -v to increase 
>>> the *verbosity* you'd want to decrease the log level towards DEBUG.  
>>> Does that sound right?
>>
>>
>>
>>
>> Let's solve the problem with naming:
>>
>> more_logging($levels)
>> less_logging($levels)
>>
>> So, a user never cares whether more_logging(3) sets the constant from 
>> MAXINT to 30,000 or from 0 to 3, just that we're getting getting 
>> three more levels of verbosity than we have right now.
>>
>> I'd also recommend we have something ALA syslog for all us soon-to-be 
>> ex-syslog(3) users:
>>
>> $log->syslog_level($SYSLOG_LEVEL)
>>
>> which does the appropriate mapping, and maps things like NOTIFY to 
>> WARN, as NOTIFY doesn't exist in log4perl land.
>>
>> And, I'd even say we should push these back to the log4j guys, as 
>> they seem pretty useful to me. :)
>>
>> -e
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: OSDN - Tired of that same old
>> cell phone?  Get a new here for FREE!
>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>> _______________________________________________
>> log4perl-devel mailing list
>> log...@li...
>> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>
>
>