Re: [PEPr] Proposal for Logging::Log4P

On Mon, Dec 19, 2005 at 12:52:35PM -0500, Philippe Jausions wrote: > > 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? I'm been semi-following this proposal as I've been getting ready for my holiday vacation, but I'll toss out a response while I have a few minutes. I (personally) only see a limited usefulness to this package. It admittedly doesn't provide any additional logging functionality, instead focusing completely on abstracting away parts of the existing Log package in an effort to provide a "lazy" interface. The implied goal appears to be to encouraging developers to log more events by lowering their barrier to entry. I submit that the existing Log package already meets these goals. Logging using the current Log package is already trivial. Once you have a Log instance, all you need to do is: $log->debug('message'); ... which is at least as simple as the proposed version (and slightly faster in terms of runtime overhead): Log_Static::debug('message'); Of course, the former requires that you already have a Log instance available if your current scope. The proposed Log4P implementation uses an INI file system to create one for you, an approach that I don't really like. PHP can already be used as a dynamic configuration language, so I don't see the usefulness in using another text-based syntax to define a PHP object's configuration. Instead, just use PHP: $conf = array('lineFormat' => '%2$s [%3$s] %4$s'); $logger = &Log::singleton('file', $filename, '', $conf); I suppose if the Log package's handler configuration was exceptionally complex, you might want to simplify it by hiding it behind a configuration file, but it's not, as seen above. (Granted, I didn't apply all of the configuration options to this 'file' handler, but you hopefully get the idea. Furthermore, this example stresses the fact that the Log package provides reasonable default values for all of its handlers, so configuring a handler hardly ever requires specifying all of the possible options.) You can still achieve a site-wide configuration by using a shared PHP include file to define your loggers. Even better, you can parameterize their creation using PHP and environmental variables. Lastly, the goal of providing a more "error_log()-like" logging interface interface can already be realized using the current Log package. See my example from the Log Package's Users Guide: http://www.indelible.org/pear/Log/guide.html#logging-php-errors Using this method, you can "lazily" log events from anywhere in your code using PHP's builtin trigger_error() function: trigger_error('message', E_USER_WARNING); So, in conclusion, I'm -0 on this package proposal, and I don't see any value in integrating it into the existing Log package. However, I respect the fact that some people may prefer to log in the style provided by Log4P, despite what I've said above, so I certainly won't oppose its adoption as an independent package. -- Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)