Re: [PEPr] Proposal for Logging::Log4P

Michael Kahn wrote: > Hi Arnaud: > > It's meant to be a container (as opposed to a handler) for the PEAR::Log > framework, mainly as a convenience for sitewide logging, and kind of a > PEAR::Log capable version of the PHP error_log() function. The main > difference over PEAR::Log is you don't use factory methods to create and > use a Log instance, you just make static method calls to the Log4P > class. Can't we have this merged into the PEAR::Log package, since this is just basically a wrapper to the singleton/factory methods? Otherwise, "Log_Static" would be better, although not best... "Log_Auto" (refering to the auto-loading of configuration)? An ini-style configuration file controls what is logged and > how--you can hook up several different logs (PEAR::Log instances) on a > per-package or per-class basis. I'm not too big on the "first-found" idea, but it is indeed convenient, but sometimes hard to debug. I think a RFC on how to initialize PEAR classes using such mechanism is due. This actually "belongs" to the PEAR framework itself. Other packages also rely on .ini files, DB_DataObject comes to mind. > There is a PHP port of the Apache Log4J project that is (unfortunately) > also called log4p, and it is not the same as this. I've been using it > too long to change the name though, unless it gets accepted as a PEAR > package and this is a requirement. My main issue with the Log4J port is > the reliance on a concrete instance, since you can't (at least as far as > I am aware and as of this writing) do this in a PHP class def ... > > class MyClass { > protected $log = LogFactory::getLog(__CLASS__); > > } In PHP the code above would belong in the constructor. > > ... which is an essential way you hook in log4j (well, the way I do it > through the Apache Commons Logging interface) in Java. Thus, for PHP I > went with a static method approach, and the Log4P class takes care of > managing log instances according to the calling class (I see > $GLOBALS['log']->debug() type stuff in many codebases, and I don't like > it!). Me neither... Log4P uses a trick that I hope doesn't change in the PHP > codebase: if you call a static method from within a PHP object instance, > inside the static method $this will still be set to the calling > instance. It works, but is it wise to use it? That could be become "broken" (read repaired) in future versions of PHP. The parser could become ticked off by a "static" / $this combination. This makes the Log4P approach even easier than Java-style > logging, since you can make logging into a one-liner, with no instance > binding and configuration separate from your application code: > > Log4P::debug($somedebugstatement); > > Anyway, the Log4P package isn't meant to solve all the same problems as > the PEAR::Log package, just a subset that is a common application of the > Log class. I find it really convenient to use, and thought others might > too. > > Cheers, > > Michael -Philippe > Arnaud Limbourg wrote: > >> Michael Kahn wrote: >> >>> Michael Kahn (http://pear.php.net/user/mkahn) proposes Logging::Log4P. >>> >>> You can find more detailed information here: >>> http://pear.php.net/pepr/pepr-proposal-show.php?id=333 >> >> Hi, >> >> I wonder if it is meant to be used on its own or as a PEAR::Log >> container ? >> >> Arnaud.