Hey Michel - definitely an interesting package. One thing I would consider doing is moving the PHP_FunctionCallTracer code into a class of its own that can be instantiated, then use PHP_FunctionCallTracer as a static interface to it. The reason being to allow named instances of the tracer to be used:
Which would just drop it into the default instance. That might be a case for adding setDefaultInstance($name) to it as well to allow you to set the default instance to use so you could change that around as necessary.
The naming of instances could be handled internally to PHP_FunctionCallTracer, but the object itself is already having to keep track of a lot of information, adding one more layer to it just seems add more complexity when a slight refactoring helps segregate the changes.
Also, the code appears to have moved beyond function calls to include all manner of calls (object methods, static methods, etc.); might PHP_Tracer be a better name? That would allow you to expand out into tracing straight procedural code as well. I can think of a few projects something like that would have been useful in.
One final note: nice work on the unit tests... It's nice to see packages proposed with them :-)
Reply to Travis
Hello - The extension you are proposing sounds interesting. This could be the next package enhancement if it makes it through the proposal process :-) Let's talk about that then, so I better understand how it could be implemented and used.
As far as the package name, I understand your point but I believe PHP_Tracer is too generic. PHP_FunctionCallTracer is really about tracing function/method calls. I am using the word function just like in PHP where it is used to declare both functions and methods. So, I guess I would like to stick to it for now. Let's wait and see what others have to say.
Thanks for your comments on the unit tests. I also hope you found the examples useful.