>> require_once "PHPTAL.php";
>> // 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
> 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