could you elaborate?
|// do something when a file is loaded...
declare(ticks=2) {
static $inclen = 0;
|| $files = get_included_files();|
| if (count($files) > $inclen) {
$loaded = $files[count($files)-1];
echo "we have loaded " . $loaded;
}
$inclen = count($files);
}
|
Anyways, I do not think that the majority (I will not attempt to make any guesses as to the exact numbers) of the current users will necessarily leverage any of these proposals. I think we are getting rid of an issue some people that are not using PEAR had. I think we are also opening up a lot of possibilities that people will appreciate if they discover that they have a need for this.
I think at this point I am tired of having to repeatedly show the potential benefits of this proposal. What I think is much more worthwhile would be to focus on exactly what we are loosing if we move to this proposal.
1) IDE's and humans can easily grep for require_once
For IDE's I do not know the impact. For humans I think you can just as well grep for "new". You can also hook debugging mechanisms into __autoload(), which would be a run time thing versus being able to grep just the code on disc.
2) include_path is a config thing, while __autoload is a run time thing
Auto prepend does not seem like an equally good solution
3) overhead from calling __autoload()
I tend to think that the inherit lazy loading nature of __autoload() will offset this issue for people not using a byte code cache
4) predictablity / clarity -- although it's partly related to 1)
calling new, instanceof etc. could do absolutely anything, someone examining code has to dig up where the autoloader is defined to understand the code.
user defined autoloads could be broken or misbehave in strange ways...- more bugs on pear bugtracker that have nothing to do with pear...
5) proven solution
It's worked perfectly well for 4+ years... ?
Regards
Alan