If I get the behaviour of SPL Autoloader correctly, it acts in a "global scope", right? If we have, say, this code:
class Autoloader {
protected static $instance = NULL;
public static function get_instance() {
NULL === self::$instance and self::$instance = new self;
return self::$instance;
}
public function init() {
spl_autoload_register(array($this,'autoload'));
}
private function autoload() {
// to the autoload magic
}
}
$autoloader = new Autoloader();
$autoloader->init();
// or
add_action('muplugins_loaded', array(Autoloader::get_instance(),'init'));
... it applies to the rest of the application OR if hooked to Wordpress action, from the hook onwards, right?
It just seems to me that it is not very convenient, especially if you work in the frame of larger frameworks (such as Wordpress). Is there way, how to limit the scope of SPL Autoload to specific context by:
- defining the SPL Autoload different way?
- having something specific in the function (such as
return false
on e.g. classes which names does not much some sort of pattern)? - something more clever?
I know, that I can add some conditional statements to autoload()
function to avoid conflicts and errors, it just does not seem very efficient.
Thanks! And yes, it is very possible that I'm just overlooking something.
Edit
Mimicing directory structure by namespaces: It's not actually possible within Wordpress, is it? If what you're after is some sort of communication and logical structure between, say, must-use plugins and themes. (@RoyalBg)
Not finding a file: How to determine than when it is "okay" to not finding a file and when it is not? By logic of the function? It still seems to me, that reducing the scope of autoloader would be way more elegant sollution. (@Jon, @Mark Baker)
But if I understand your comments well, SPL Autoloader truly applies "globally" by default.