OK, we are in agreement about removing the $caller then.
I propose that we work on parameterised logging for 2.2 and consider
markers for the next release to achieve a smaller release cycle.
The logging methods will be rewritten to support:
Logger::debug($message); // standard
Logger::debug($message, $obj1, $obj2, ...); // parameterized
Concerning the parameter syntax, i think the one used in SLF4J (using
"{}" for parameters) is the most elegant. So, for example, one could call:
Logger::debug("Object one: {}, Object two: {}", $obj1, $obj2);
What do you think?
Regards,
Ivan
On 8.8.2011. 17:04, Christian Grobmeier wrote:
Looking at the code, this is a pretty historic artifact.
My guess is, it was the intention to use the "exception generating"
class as a $caller.
But on the other hand, there is enough information in the exception
itself (which was probably not the case when this argument has been
introduced in PHP4 times). So I cannot see any good in this. Therefore
I am +1 for removing it, even when it breaks the interface.
In addition I would think that the parametrized messages or Markers:
http://bit.ly/qpjKDL
http://www.slf4j.org/faq.html#paramException
could bring more benefit at all.
Cheers
Christian
On Mon, Aug 8, 2011 at 4:11 PM, Ivan Habunek<[email protected]> wrote:
The main logging methods (Logger::trace(), Logger::debug(), etc.) currently
take two parameters: $message and $caller.
I traced the path by which the $caller parameter is passed on and it goes
like this:
1. The main logging methods pass it to Logger::log()
2. Logger::log() passes it to Logger::forcedLog()
3. Logger::forcedLog() checks whether $caller is an exception and if it is
passes it to the LoggerLoggingEvent constructor as $thorwable (otherwise it
is ignored).
4. LoggerLoggingEvent constructor embeds it into $this->throwable.
This frankly makes no sense to me.
Is $caller is there to allow the user to add additional throwable
information along with a message? If so, I don't think that it works the way
it is implemented now.
Is this a remenant of some previous functionality? I cannot find a use case
which demonstrates it's usefulness.
If it serves no function, I propose that this parameter is removed. This
would enable implementation of parameterized logging similar to that of
SLF4J, as discussed in LOG4PHP-119.
Best regards,
Ivan
