The framework that I use (Zend) has an autoloader built it. I think this autoloader takes care of loading, not only Zend itself, but also any other libraries the developer may add to the project.
Is it normal practice for a framework to have an autoloader? Any that don't have?
Is it necessary to have an autoloader?
ZF's Autoloader will by default only load ZF's classes. It can (and is supposed to be) configured to also load your custom classes and you can also add additional Autoloader from other frameworks. ZF 2 will have a classmap autoloader in addition to the PSR-0 autoloader. See the Blog Post by ZF's Matthew Weier O'Phinney on Autoloading Benchmarks
Yes, it's common to have autoloaders because you dont want require statements all over your code. It's not strictly necessary though. The native way to achive autoloading is with spl_autoload_register.
Not it is not necessary, but it is very convenient. You don't need a hell of a lot of includes or requires, and units are only loaded when you need the class it contains. And that helps you stucture your code too, because incorrect naming will cause the autoloader to fail.
As stated by other members that not every framework has an Autoloader but I believe that every framework should.
If you can understand what a framework does than you should understand that there designed to be modular, being able to add and remove components easily, if you was to hard code all your libraries models, controllers etc then when you add new libraries you would have to recode for the library to work.
So that's the convenience part of the autoloader, the other part is the performance and resource management side of it, The base idea of the autoloader is to load the files only when required.
so on your index.php page you may need 5 libraries, but on your register.php you may only need 2 libraries, so that using an autoloader will save you 3 includes on your register page.
It also allows a better file structure as your components are separated and organized.
as you may be looking into placing an autoloader into your framework i strongly recommend you look at the PSR-0 standards that is currently in use in Zend and many other high end framework, the link can be found below:
http://groups.google.com/group/php-standards/web/psr-0-final-proposal
Yes, it is a common practice to include autoloader in the framework.
No, I can not think of any major framework without autoloader.
Yes, it is necessary if you want the framework to be flexible enough. It eases the addition of modules / classes to simply copying the files to the correct directory and invoking them from within the code. Autoloader just includes proper files instead of including all of the files (even if they are not needed at the moment).
Additionally, the way the classes are autoloaded can be determined completely by the autoloader mechanism, enforcing eg. proper directory structure or enforcing prior declaration of classes / files that can be autoloaded.
Many frameworks do have autoloaders, one that does not is CodeIgniter and you have to specify which classes you want to load all the time and which classes you want to load inside your controllers / models / views / libraries.
It isn't completely necessary, but it is nice because it generally enforces a file structure and you also don't have to worry about remembering to include files at the top of your scripts.
[Edit]
Apparently clarification is needed on my CodeIgniter statement. Yes there is an auto_load place that lets you specify the libraries/modules that you want to load automatically at the start of every script, and yes there is a loader library, but they are not the same as a real autoloader.
You have to specify which ones you want at the start, it doesn't know that you want to load the Pizza_Store modle until you use the custom
$this->load->model->('foo');
which is equivalent to
include 'application/models/foo.php';
$this->Foo = new foo();
But is not really the same as only having to call $this->foo = new Models_Foo(); and CodeIgniter knowing what you mean by it, which is what happens when an autoloader is used.
[Edit part deux]
Nowehere in the code does it say __autoload, spl_autoload or spl_autoload_register. This is because it maintains PHP 4 compatibility. It is just the way that the framework has been built, there is a false autoload as I stated above, but it does this for each "autoloaded" class:
foreach($autoloaded_class as $type=>$class){
if(is_application_class($class)){
include "application/{$type}/{$class}.php";
}
elseif(is_core($class)){
include "core/{$type}/{$class}.php";
}
}
$array['Foo'] = new Foo();
$controller($array);
Which is essentially calling:
include 'foo.php';
at the top of every file no matter if you need it or not.
Related
I have a "simple framework" whose main instance is $app. Now, what is the best way to implement an autoloader (without using Composer). What I need is to have a class which handles all the autoloading (supporting the various namespaces). I have a few approaches/dilemmas.
At first I thought I should create a "static" class which handles everything. But then something came to my mind. If I use the autoloader before instantiating $app (which contains all the paths), I would need to define the paths outside of $app. And also if an error occours in autoloading a class, I wouldn't be able to handle the error properly (error handler is inside $app, and instantiated after).
Then I thought of dependency injection, making the autoloader an object inside the app. That would resolve the error handling problem, and wouldn't need me to hard code paths or making them globals. But I would have to load many classes (including $app) too before I can instantiate the autoloader.
But really I'm in a world of pain because of this issue, I don't really know where to start, are there some advices I should take into account ? Can you explain me which method should I use and why ?
Thanks.
As a result of the tips I got in this questions, I searched a bit more and found good resources from where to learn.
What's Autoloading ?
Autoloading is basically the process in which the program finds an unknown Class Name and attempts to load it without Class Name being defined. Without an autoloader, this behavior would result in a fatal error (for PHP at least). With an autoloader, things change, and the program will attempt loading Class Name, without knowing where to find it, but relying on functions or classes thought for this purpose, those functions/classes are called Autoloaders.
__autoload() vs spl_autoload_register()
In PHP we have two different ways to achieve autoloading (you might find useful to read it from PHP's site.). The first one is the old __autoload(), the newest is spl_autoload_register(). But what exactly is the difference ? Basically __autoload() is unique, having multiple Autoloaders would cause you many troubles and would get you in solving a problem which can be easily avoided by using the newest spl_autoload_* functions. spl_autoload_register() on the other side allow the program to have multiple Autoloaders by putting them in a stack, in this way the whole system becomes more flexible and much less complicated (having a single Autoloader for different purpose results in having a big unique function handling many requests, this way you'll have less code maintainability and reusability).
Warning: using spl_autoload_register() will overwrite __autoload(), so be careful.
Coding standards (in PHP): PSR-0 vs PSR-4
Let's start by saying that PSR-4 is newer and it was thought to be an improvement of PSR-0, but not compulsory you must use 4 instead of 0, as the standard (PSR-4) states:
It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0.
So why should I use one instead of the other ?
Now this is up to you, but as a suggestion PSR-4 solves the "nesting" problem PSR-0, so you should be using the former. Let's suppose I have an application, and my application relies on external components, PSR-0 follows this syntax:
\vendor\(sub_namespaces\)class_name
Where sub_namespaces might be absent. But that translates to a fully qualified path on the hard drive:
path/to/project/vendor/sub/namespaces/class/name.php
Now let's suppose I want to include a library called YourLibrary in my application
\YourDeveloper\YourLibrary\YourFunction
This would translate to
/path/to/project/YourDeveloper/YourLibrary/YourFunction
And here's the problem, what if I want to put that library in a subfolder of mine:
/path/to/project/vendor/vendor_name
PSR-0 is absolute, you can't just modify the namespace to control this behaviour (it would be silly and require too much time) so it would translate to this:
/path/to/project/vendor/YourDeveloper/src/YourDeveloper/YourLibrary/YourFunction
Isn't that extremely nested and redundant ? Well, using PSR-4 you can avoid that and transform that into
/path/to/project/vendor/YourDeveloper/YourLibrary/YourFunction
Without altering the namespaces or the Autoloaders. That's basically how PSR-4 works. This explanation is quite short, but it gives you a glance of why PSR-4 was born and why you SHOULD use it. If you require a more adequate explanation, you can go and read the PSR-0/4 specifications or you can read this beautiful article on sitepoint.
Should I really be caring about standards ?
If you have been in the world of programming for enough time, you probably won't end up asking such question. But if you are, you are probably a new programmer, or you haven't been a programmer long enough, that's why you SHOULD read this answer.
In the IT world, and especially in programming, standards are almost everything. If we hadn't followed standards, we might not even have videos on our computers. If anyone follows their own standard, everything would look messy, and in this case, Autoloaders would become personal; so instead of having one SIMPLE Autoloader, you would end up having many Autoloaders, one for each standard, making your application much more difficult to maintain and to debug (because everyone can make erors).
If you writing a framework you should always look at existing ones, which properly allready solved your problem. Then you get inspired or just use that component. A great starting point is symfony, their components are seperated and tested. If you load it with composer or download it manually is your choice ;)
They also have a Classloader http://symfony.com/doc/2.0/components/class_loader.html which you could use as it. Or you just take a look what their approach is.
The Autoloader (or your classloader) should be the included at the beginning of your application and this should be the only class you include directly.
If you want to load your class dynamic your have to take a look how your store your classes, there are diffrent "standard" ways like PSR0 http://www.php-fig.org/psr/psr-0/. If you want your users to add their own classes, when they using your framework you should consider to support multiple standards.
I will use __autoload function in Codeigniter, but I'm not sure what is the best way.
I have read Phil Sturgeon's article and he uses at the bottom of config.php and
I asked to my friend, he uses in index.php
But I think they are not clean usage.
I want to use it in hook but I read this answer( last answer in the page ) How to add autoload-function to CodeIgniter?
and there is a negative vote on it.
Is to use in hook not good solution?
Codeigniter's autoload system is the easier way if you're using that framework: you just add the classname as index of an array and you're set.
Technically, it's not a "proper" autoloader, is a registry that checks if the class has already been instanciated in the static array of classes and, if not, adds it. In the way CI works it's efficient enough, and more important: is way easier for the user, compatible with any php version, and you don't need to code anything to implement it.
A proper autoloader using the __autoload() magic method, or better with spl_autoload_register() means you need to separate your loaded classes from what loads CI, and you need to implement it manually.
For future-ready applications check the PSR-0 standard which gives you indications on how to build a "standard" autoloader to be used to load classes in what's becoming the trend in PHP world: package management and distribution, similar to what other languages already do.
I don't understand what spl_autoload_register or autoload is doing.
Why wouldn't I just use include or require?
I didn't see a clear cut answer.
The advantages of an autoloading function or class are:
If you have a lot of classes, you don't need to manually include them. Take Zend Framework as an example: You don't want to load all of those classes manually. With an autoloader, just create a new class and start using it in all of your (autoloader-enabled) files.
Only files that are actually used in the request are loaded, potentially saving resources. If you only use 10 out of 50 files, why load the other 40?
It forces you to have a sensible directory layout (after all, you'll need some rules so your autoloader can find files).
It can (but not by definition) be faster than including manually. The benchmark in the linked article shows that if you use about three quarters of all of your available classes on your page, you'll 'break even'. Even then, autoloading makes your life so much easier that even if it was significantly slower than manually including, you should still do it.
Currently I load in all my classes by including a "all.inc.php" file on every page of my site, this file then goes on to include all the config, classes, functions, etc. that I will use on the whole site.
My issue with this is that often I use classes that only pertain to certain pages/sections of a website, so often I am including a bunch of classes at the start of the page which will not be used.
Obviously autoloading the classes would fix this issue, so my question is, would autoloading the classes give me a performace downside as the server then has to check if a file exists? And if there is a downside, then is this downside worse than having to include a number of classes that may not get used on the page? Or is the difference negatable?
This article has some information and benchmarks: PHP autoload performance (archived). Conclusion:
Autoloading does not significantly degrade performance. Include_path lookup, reading and parsing PHP scripts from disk takes much longer time than that bare autoloading logic costs.
Autoloading a class is almost as fast as including the class in the normal way. Switching to autoloading will improve performance in your case, because PHP loads less files and classes.
Autoloading will improve the performance if the script does not have to search the files each time in the filesystem. If you use namespaces you can have a nice mapping of the namespace and class name to a folder and file like Some/Nice/ClassName would map to Some/Nice/ClassName.php.
If you do not use namespaces and have to search through folders I suggest you to create a custom singleton class to include files that allows you to do something like:
App::uses('Some/Nice', 'ClassName');
In Autoload use the registered path and class name to map it to a path and file combining both args from the uses method in my example. This will allow you some namespace like functionality for class loading until you're ready to change your app to use namespaces.
You should use autoloading with cache index of all available classes/files in project.
Example:
$class_cache=array(
'MyClass'=>'lib/MyClass.php',
'Item'=>'model/Item.php'
);
function __autoload($class_name) {
if(array_key_exists($class_name))
include $class_cache[$class_name];
else
throw new Exception("Unable to load $class_name.");
}
You need to keep class list actual or write some generator for $class_cache.
Each include() and require() (and their _oncesiblings) carry a performance penalty on their own. Disk seeks and reads also come at a cost. It really depends on your code, if you are loading 20 classes but use only 2 or 3 at any single point, then it's definitely worth going the autoloading route.
If performance is your main concern, you should look into merging your class files into a single file and instantiate what you need.
A really old question, but all the answers were actually wrong.
... autoloading takes a significant amount of resources. The number varies a lot and that’s maybe not what you’ve seen in your own app, but a typical 10% wouldn’t be surprising.
from CTO of Blackfire.io, so I'm sure he knows what he is talking about. Read more here
I'm building my personal CMS and need your advice organizing core functions and classes.
I have folders:
/shared
/classes
DB.php
Session.php
Config.php
...
/libraries
Arrays.php
DateTime.php
Email.php
...
The files in 'classes' folder contains core classes (one class per file).
Now the question is about /libraries/ - they contain functions that may be used in any class, and sometimes they use some other function from another library, and sometimes they need to access some core class.
Should i just write them as functions, or make them static and wrap in some class?
Basically i need them everywhere, but keep them organized.
Should i just write them as functions,
or make them static and wrap in some
class? Basically i need them
everywhere, but keep them organized.
Have you looked into namespaces yet? Wrapping all of your functions into a namespace would probably be your best bet.
My suggestion is to first think through about the architectural goals of your CMS. Sure, it's going to be 100% yours, but that doesn't mean you wont suffer from not begin sure whats hooked where and how, what this does and how do I get that from here.
That's why I definitely wouldn't suggest you have libraries calling libraries. From my point of view, none of your classes should be dependent on anything else except for the first few core classes in your application flow since you'd like to distributed the work in some other single purposed self-contained classes. You should aim for singularity and atomicity with your core classes.
I don't know what your architectural pattern will be (I'll presume it's going to be MVC, HMVC or PAC), but I think it's best you first define a few core classes [/core] that will lay the foundations on initializing the application by instancing some libraries [/libraries] that are required for parsing the incoming requests request and doing some default tasks before initializing the requested controller [/controllers].
Libraries should have a single purpose. The session handling library should solely handle sessions, the routing library routing, etc. Initially you can create your base controller and base model and put it in [/core] and have controllers [/controllers] and models [/models] extend your base controller and model from [/core].
As always, the less coupled your components are the better. A good solution will be lightweight, small and extensive in it's purpose. It helps if you change any design ideas in the future that you can simply change the core classes and have a huge impact on the whole application without having to make any further changes in other places.