There is a ticket (http://tracker.phpbb.com/browse/PHPBB3-9923
) with a proposed patch, objections to it here, and no clear conclusion.
naderman wrote:In my opinion MODs should simply name their classes phpbb_<modname>_whatever. These files should be placed in the includes directory where all autoloaded classes reside.
This is a valid workaround, does everyone agree?
igorw wrote:If we want phpbb_mod_classname and /mods/classname.php it might be good to have it dynamic, but that's not been decided yet.
I don't think we should make an expection for the phpbb_mod_ prefix, but rather just call the directory "mod" instead of "mods". This is much more straight foreward.
This I like.
igorw wrote:add_loader seems like a bad idea to me, it adds complexity. A better approach here imo would be to just create a second separate class loader instance and call register() on that.
This I also like. Making "include" into a parameter seems less contentious. How about making "phpbb_" prefix into a parameter? Or a property that can be overridden?
With these changes core autoloader should be usable by just about anything matching our directory structure conventions.
Erik Frèrejean wrote:I'm not sure whether I like this, if you for example have 4 MODs installed that all use a different class loader you'll end up with 5 instances of the class loader. IMHO this clutters the code more than needed as the class loader can easily accommodate variations (different include path/class prefix).
What is the difference between creating another autoloader and registering it vs modifying the core autoloader? It seems to me that it would be negligible. Looking at our autoloader there won't be much duplication of data either.
I would prefer not having code in the core that the core does not need (add_loader and related code) when there is a simple alternative requiring roughly the same amount of effort on the part of modification authors.