Autoloading?
Permalink 2 users found helpful
Why does concrete5 require this Loader nonsense when php5 supports autoloading?
I agree that magic has its drawbacks but it is not always a bad thing. Autoloading, if done well, can improve performance. And looking at the code in the Loader class I do not know why a well made autoloader would be any worse.
If I need a particular class and I use the Loader::library() or Loader::model() methods I have to use those methods every time I need that class since I don't know if that class has already been loaded someplace else. Wrapping the loader call inside a condition that checks class_exists doesn't strike me as a user friendly option. Then it checks if the file exists, which it may have to do repeatedly depending on where the file is located. Then once it finds the file it has to do a require_once which is more costly than a require since require_once has to see if the file has already been required.
If concrete5 must use this Loader class it should at least keep track of which files it has included so that it doesn't have to do so much work every single time when this is really only necessary once.
With better class naming conventions such as those used by the Zend Framework an autoloader could be as simple as
Such a simple autoloader may not be practical for concrete5 which would require several include paths but it shouldn't be too difficult to come up with something that works better with the concrete5 layout.
If you want something really fast you could look into what they are working on for the ZF 2 autholoader which scans the application files to create a class path. Think of an array where the key is the class name and the value is the file path. This would be compiled when deploying the app but concrete 5 could make it an option inside the admin and could auto run it when installing or upgrading packages.
Anyways, I still think an autoloader would be far better than the current solution.
If I need a particular class and I use the Loader::library() or Loader::model() methods I have to use those methods every time I need that class since I don't know if that class has already been loaded someplace else. Wrapping the loader call inside a condition that checks class_exists doesn't strike me as a user friendly option. Then it checks if the file exists, which it may have to do repeatedly depending on where the file is located. Then once it finds the file it has to do a require_once which is more costly than a require since require_once has to see if the file has already been required.
If concrete5 must use this Loader class it should at least keep track of which files it has included so that it doesn't have to do so much work every single time when this is really only necessary once.
With better class naming conventions such as those used by the Zend Framework an autoloader could be as simple as
require str_replace('_', '/', $class) . '.php';
Such a simple autoloader may not be practical for concrete5 which would require several include paths but it shouldn't be too difficult to come up with something that works better with the concrete5 layout.
If you want something really fast you could look into what they are working on for the ZF 2 autholoader which scans the application files to create a class path. Think of an array where the key is the class name and the value is the file path. This would be compiled when deploying the app but concrete 5 could make it an option inside the admin and could auto run it when installing or upgrading packages.
Anyways, I still think an autoloader would be far better than the current solution.
It seems you're arguing the benefits of a low-level sub-routine written in C, when Concrete5 is written to harness the power of open-source development, contributions and per-developer manipulation of the system so as to meet specific needs. Having a clearly defined method of loading specific items helps this cause. Saving a couple of controller logic steps is - in my view - not worth the added difficulty your idea might present.
As stated before, a development 6 years in the making and then provided as open-source for the community to expand upon will no-doubt come with some things that could be redone. Personally, I find huge benefits upon which to build and develop. I think others do too.
As stated before, a development 6 years in the making and then provided as open-source for the community to expand upon will no-doubt come with some things that could be redone. Personally, I find huge benefits upon which to build and develop. I think others do too.
Concrete5 does have, and does use, an autoloader, which can be extended, however, using Loader:: is far more efficient and introduces less "Magic" into the code, which is always good...
Jon