tags:

views:

112

answers:

2

Hello,

Is there a way to shortcut this:

function a($where){
  echo $where;
}

function b(){
  a(basename(__FILE__).'::'.__FUNCTION__.'()::'.__LINE__);
}

to something like this:

    define("__myLocation__", ''.basename(__FILE__).'::'.__FUNCTION__.'()::'.__LINE__.'');
    function a($where){
      echo $where;
    }

    function b(){
      a(__mYLocation_);
    }

I know that this cannot be done with constants (is just an theoretical example), but I can't find a way to shorthen my code. If a use a function to get my line it will get the line where that function is not the line from where the function was called.

I usualy call a function that prints directly to the log file, but in my log I need to know from where the function was called, so i use basename(__FILE__).'::'.__FUNCTION__.'()::'.__LINE__ this will print something like:

index.php::b()::6

It is a lot of code when you have over 500 functions in different files. Is there a shorten or better way to do this?

Thank you.

A: 

Ehh.. I guess you could do that with eval and that constant.

define("__myLocation__", "''.basename(__FILE__).'::'.__FUNCTION__.'()::'.__LINE__.''");
function a($where){
  echo $where;
}

function b(){
  a(eval(__myLocation__));
}

But you really shouldn't be using eval for anything.

St. John Johnson
+1  A: 

debug_backtrace() should help you, although I don't know what the performance hit would be making a call to it every log you cut. Try this:

function cut_log() {
    $trace = debug_backtrace();
    echo basename($trace[1]['file']) . '::' . $trace[1]['function']
         . '::' . $trace[1]['line'];
}

function a() {
    cut_log();
}

a();
wilksm
you dont want that in production code.
Gordon
@Gordon As it turns out, `debug_backtrace` doesn't add very much overhead. I'd say that if it works, use it.
mattbasta
@mattbasta it's not the overhead, it's by principle. this is a debug function, primarily used in error handling. It shouldn't be misused to get information about a caller object, unless it is for debugging and logging is not. See http://stackoverflow.com/questions/346703/php-debug-backtrace-in-production-code and http://www.mail-archive.com/[email protected]/msg43737.html
Gordon
@Gordon This seems like a very appropriate place for `debug_backtrace` to be used. Even though this isn't for errors, who cares? It returns the information the op needs and it does it quickly. This is for a logging suite: exactly what `debug_backtrace` was built for. Sure, it's not handling errors, but it's serving it's purpose: to describe the context of execution. There is no reasonable argument *not* to use `debug_backtrace` in this instance.
mattbasta
@mattbasta I guess, we have to agree to disagree then. Logging arbitrary user activity is not debugging and it's not what `debug_backtrace` was built for. If the logger needs this information about the caller, it should be passed to it. That is *much* faster and appropriate than creating a full callstack on each logging. That's sufficient reasonable arguments to me. Here is some more more people agreeing with me: http://stackoverflow.com/questions/2438356/is-debug-backtrace-safe-for-serious-usage-in-production-environment
Gordon