>> require_once "PHPTAL.php";
>> spl_autoload_unregister(array('PHPTAL','autoload'));
>> // if needed: spl_autoload_register('__autoload');
>> Would that be OK?
> Wouldn't that cause issues when PHPTAL needs to load more classes
> during the course of the script's execution?

I think the idea is that this code would go in the host app and could be used 
to unregister the phptal autoloader as soon as it has been registered as part 
of the require_once on phptal.php. You would only do this if you already have 
an autoloader.

> The autoloader stack should not cause any conflicts; if a class can't
> be found based on the naming conventions of a particular class loader,
> it will go to the next loader.

That's quite true. If the already-configured autoloader in the host app knows 
how to handle PHPTAL classes then the phptal autoloader will never actually be 

> The argument that one would only want one autoloader is somewhat weak;
> some other libraries also use their own loaders, so I see no reason to
> resist that for purity sake. I don't mind to be proven wrong though
> ;-)

It's less for purity and more for complexity and debugging. Having worked in 
the past in environments where there were multiple autoloaders all doing their 
little tricks (and, admittedly, before the spl autoloader existed) I can tell 
you that debugging code can become a very tiresome business and bugs related to 
the order in which php files are loaded become very hard indeed to track down.

One autoloader is a decent tradeoff between resource usage and code readability 
and predictability. I personally believe 2 or more autoloaders tip the balance 
away from the latter but with no additional benefit to the former.

PHPTAL mailing list

Reply via email to