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
