Hmm. I'm not entirely happy that the API is different depending on where you're calling ->log from.
Well, the API is exactly the same; it's a multidispatch based on the number of parameters. It just so happens that the plugins get a wrapper around the base call which prepends additional values so the logger can tell where it was called from.
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.
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.
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.
John
