On 15 Mar 2005, at 10:05, John Peacock wrote:
Are there plugins out there that call $self->qp->log()? I think there might be.
And they will still work exactly as they do now (i.e. don't get the pretty "$plugin plugin:" prefix). Since they will be called with only the tracelevel and the log string, they will just fall out like the "core" log entries.
Only if they only have two parameters is what I'm trying to say.
It just feels a little hackish to me to differentiate how it works depending on number of parameters. Wouldn't we be better with separate ->log methods for internal functions and leave the generic ->log() method as it is now for plugins to call?
The main problem with this is the second phase here is to have a pluggable logging plugin, which would have to be called for both of the methods. I'd rather get the benefit of a single sub log() to dispatch from.
sub core_log {} # new method for all core logging sub log {} # backcompat method sub _log {} # this is where everything ends up
One of my promary goals is to not touch any existing code that I don't have to. With my current patch, any existing code works without change in a manner almost exactly as it did before, yet I have the ability to branch in the logger based on where the ->log() was called. If I started using a hash with named parameters, every single call to ->log() would have to be altered.
I'm not fixed on the named param thing, but I still think ->log() should continue to behave exactly as it does now, even in the face of multiple parameters.
Matt.
