Re: [PEPr] Proposal for Logging::Log4P

Hi Philippe:

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)? That would be nice. Like I said before, I'm open to package name changes, as long as it's easy (ie: fairly terse) and doesn't discourage the lazy developer from adding useful log messages!

For PHP 5 only, syntax like Log_Auto($this)->debug($str); // or Log_Auto(__CLASS__)->debug($str) would work as well, and not suffer from your comment (below) about the risk of the PHP parser closing the $this-passing loophole. Plus, you could pass any scope you liked to the Log_Auto() function (short for Log_Auto()::getInstance()), not just a class or package name. If it was rolled into the Log class, you could have Log::auto(__CLASS__)->debug($str) Though it would be nice to preserve a terse approach for PHP4 too, and it wouldn't like the above syntax.

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. Well, I always put all my conf files in WEB-INF/conf in my application or site root, but that's just force of habit. I also set up all my apps to guarantee the local app context is checked first, then the site context, then the preexisting include_path.

As much as J2EE guys like to glorify Java as a language and J2EE as a platform, it's often the useful conventions, not the language or tools themselves, that provide a lot of the actual utility. PHP doesn't really have as rock-solid a "look here and you'll find..." set of conventions, though PEAR seems to be trying hard with its package/file naming conventions and other such things. I personally tend to follow the J2EE webapp filesystem layout (including using the WEB-INF/ protected-directory convention for all non-public application assets), just because it's easier to not have to bend my brain back and forth. And it seems to work well for PHP too. My point is the "first-found" approach is easy to debug if there are sensible conventions and predictable defaults, and you gain a lot in usability. And, you can always log the location of the actual file found (using this logger for most packages, and an E_USER_NOTICE trigger for the logger). "Container-managed" services often make life much easier, except when they start creeping (with no sensible defaults) towards J2EE-config-file-mania--always a balance to be struck.

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. Yeah. I like having the log calls completely orthogonal to the object model, though. It just seems cleaner.

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. I agree, though I've been using this technique for years now, but never for anything mission critical (all that happens in Log4P is it can't guess the log scope and so uses the DEFAULT). I don't use Log4P for any application-domain-context logging, just trace-style logging fro debug, warnings, etc.).

Michael