reviewed and did a couple of searches on this prior to signing up to this particular list...
Is this a reasonable consideration for changes to PHP's handling of undefined functions? Currently, calling a previously undefined function generates an E_ERROR, and halts the script as a cirtical failure meaning we can't handle the error as we do others (this is clearly documented). What I am not clear on is why an undefined function should necessarily be a fatal error with no change to code the script to handle the error. For example <?php function eh($type, $msg, $file, $line, $context){ # code to parse $msg for /undefined\040function:\040(.*)\(\)/,$match # check specified directory for the function: # include the file if exists (./functions/$match[1].php) # try to resume # if we can't find it, halt with die() } error_reporting(0); set_error_handler("eh"); undefined_function(); ?> This would seem much more intuitive, and allow collection of massive amounts of sharable and accessible functions to be contained in shared directories, and not have to worry about identifying them all at the head of all pages, or including functionsthat would not be required. Currently as a workaround we are using the following logic; <?PHP function func($f_name){ if(!function_exists($f_name)){ # function doesn't exists, needs to be included require('/path/to/functions/'.$f_name.'.php'); }else{ # function already exists, no action required } return $f_name; } $database=call_user_func(func('DatabaseConnect'),'var1','var2'); ?> But this results in code that isn't quite as intuitive. Thoughts? Comments? "You are nuts"? Dave -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php