Re: Request For Comments: Log2

From: Date: Mon, 14 Sep 2009 13:35:44 +0000
Subject: Re: Request For Comments: Log2
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-52821@lists.php.net to get a copy of this message
David, On Mon, Sep 14, 2009 at 7:31 AM, David Jean Louis <izimobil@gmail.com>wrote: > Hey Brandon, > > Brandon Savage a écrit : > >> * I'm not sure I understand your concern with regards to driver-specific >> methods. While it is true that you would have to comment out references like >> $log->addRecipient(), I would think that the rules of good design would >> dictate that the Log2 base class has no business containing those methods, >> as they do not relate to the other drivers. >> > > Sorry if I was not very clear, what I meant was that the Log class should > provide a unified entry point to the various log handlers, eg.: > > $log = new Log(); > // $name is the name of the handler (eg. 'Database') > // $options is an array containing driver specific config data > // thus, the two variables can be stored in an external config file > $log->setDefaultHandler($name, $options); > $log->log('Foo!'); > > Also, it would be great to be able to combine loggers, for example: > > $log = new Log(); > $log->addHandler('File', array('file' => > '/var/log/foo.log', etc...); > $log->addHandler('Mail', array('recipient' => > 'foo@example.com', etc..); > $log->log('Foo!'); // would log to file and mail. > I think I understand. You want me to reimplement the Log factory pattern, which allows for the generation of objects but defers the instantiation of those objects to the method itself. Something like this: $log = Log2::('Database', $options); $log->addHandler('File', $options); I think this could be accomplished, and I think that the addition of a constructor to the subclasses would make this easier to do with varying options. Note that Log2 cannot be instantiated directly, as it contains abstract methods. Log itself contains abstract methods as well, but because PHP 4 did not have the keyword "abstract" they are simply defined as methods without anything in the body, meaning you wouldn't raise an error by instantiating Log directly. > * You're absolutely right. I haven't yet written syslog or console >> logging, but that was on my list before proposing this for comments. >> * I missed adding the log level masks, but I will add them. >> * Configuring the log format and the date format are important, and I will >> add methods that allow for this before proposing this for comment. >> * Permissions were excluded from the File driver, as I generally prevent >> PHP from modifying the file system too much. However, I can see the virtue >> in having those methods. >> * You make a good point regarding concurrency. >> * The shortcut methods were intentionally excluded. I consulted with a >> number of developers who felt it was silly to have eight methods that were >> essentially identical, for the sake of typing less. >> > > Fair enough, but IMHO this is relevant for a logging package, if you make > an intensive usage of the Log class, typing: > $log->warn('some message'); > instead of: > $log->log('some message', Log::WARNING); > can help you to save some precious time. > > Every logging library I used (in python, php or perl) have such shortcuts, > i think it would be too bad to not include them, given that it's something > really trivial to implement with the __call() magic method. > > That said, this is not very important at this stage ;) > This would be a perfect use of the __call() magic method. > > >> This project came about after I chatted with Chuck Burgess, and is very >> much a work in progress and not ready for release (and your comments confirm >> that :-)). >> >> Best, >> Brandon >> > > Cheers ! > > -- > David > Brandon

« previous php.pear.dev (#52821) next »