I've seen a bunch of examples using PSR to do autoloading with namespaces. Maybe this is a dumb question, but why isn't this bad practice? Doesn't that defeat the purpose of having namespaces?
For example, say you have two libraries, FormBuilder and MySweetForms, and both have a Form class. Locations are at:
lib/FormBuilder/Core/Form.php and lib/MySweetForms/Form.php
If you autoload based on the namespaces those Form classes are in, aren't you going to run into the exact problem that namespaces are meant to prevent: ambiguous identifiers of classes and methods?
Won't it fail when you successfully locate another class in the MySweetForms namespace, say AjaxFileField, that relies on \MySweetForms\Form, but it finds the FormBuilder's implementation of the Form class?
Because of namespaces, the autoloading won't find the FormBuilder's implementation of the Form class when it's looking for the MySweetForms implementation, provided the autoloader and the two libraries follow best (or close to best) practices and are implemented correctly.
If the MySweetForms/AjaxFileField.php file defines a class inside the MySweetForms namespace as shown:
namespace MySweetForms;
class AjaxFileField
{
public function doFormStuff()
{
$form = new Form();
}
}
Then the reference to the Form class inside AjaxFileField is really a short-hand for the fully qualified class name MySweetForms\Form.
When the autoloader is invoked to load the class, it will be asked to load the class based on it's fully qualified name. A PSR-0 autoloader would translate the MySweetForms\Form classname into the MySweetForms/Form.php path, and (provided it was told to look in the lib directory) it would find it's way to the correct file. If that file was missing, the autoloader would ultimately fail. Similarly, if that file defined a Form class but neglected to supply a namespace the actual class (MySweetForms\Form) would not exist (instead, a global class Form would) -- that doesn't match the fully qualified name of the class referred to in the AjaxFileField class, so an error would occur.
Note that if the code had included $form = new \FormBuilder\Core\Form(); instead the class name would already be fully qualified, and the autoloader would be asked to load the FormBuilder\Core\Form class (and would expect it to be in the FormBuilder/Core/Form.php file).
If we had used $form = new \Form(); we would be referring to the Form class in the global namespace and the autoloader would be asked to find Form (it would look in the Form.php file directly inside the lib folder at this point).
The key is to recognize that there are not, really, two Form classes -- there is one class with a fully qualified name of FormBuilder\Core\Form and one with a fully qualified name of MySweetForms\Form -- and a properly implemented autoloader will expect them in completely different locations, and will not try to load one file in place of the other.
The combination of namespaces and the PSR style of organizing files into directories based on their namespaces makes it very easy to re-use common words without causing conflicts, and to predictably map fully qualified class names to the corresponding files.
The resolution of class names to fully qualified class names is key to this, and is discussed in the PHP manual (the namespace FAQ has a couple of points about it: http://www.php.net/manual/en/language.namespaces.faq.php). The PSR-0 standard itself is also a useful reference: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md
Related
I am having a problem with my namespace fallbacks and using PSR-4 loader in Composer.
What I am trying to do is this:
Have a core which can overwritten / extended.
The core is based off an interface.
The directory structure is like so:
site/app/View/Example.php
site/src/ACME/app/View/Example.php
site/src/ACME/app/Interface/View.php
I am not set on this configuration so if you have a better suggestion then go for it.
My composer json is like so for psr-4:
"autoload": {
"psr-4": {
"ACME\\App\\Site\\" : "app/",
"ACME\\App\\" : "src/AMCE/app/"
}
}
I thought this would make ACME\App\Site\View fallback to ACME\App\View if the site one was not found (Note I haven't done the interface part yet...).
My code for site/app/View/Example.php is like so:
namespace ACME\App\Site\View;
class ViewExample extends View {
Which works, when I have site/app/View/View.php as well. That looks like:
namespace ACME\App\Site\View;
class View extends \ACME\App\View\View {
The site/src/app/View/View.php look like this:
namespace ACME\APP\View;
class View {
This one should use the interface (I haven't tried yet).
So what I really want to do is make it so I don't have to have site/app/View/View.php, and I don't have to have site/app/View/Example.php - it can use site/src/ACME/app/View/Example.php.
Sorry I'm new to namespaces so I may not of phrased it very well.
What I am getting at is I thought ACME\App\Site would fallback to ACME\App - it doesn't? Or I am doing it wrong? At the moment it needs all the files in place.
Edit: Turns out I was originally wrong, it is possible to get your example working with PSR-4! You just need to specify an array of directories for namespaces that can be loaded from different places.
Easy solution
{
"autoload": {
"psr-4": {
"ACME\\App\\Site\\": ["app/", "src/ACME/app"],
"ACME\\App\\": "src/ACME/app/"
}
}
}
Personally, I would rather name my namespaces more explicitly, see below.
Original Answer
The composer PSR-4 loader does not fall back when trying to load files that do not exist. It just fails immediately. Its flow looks like:
\ACME\App\Site\View is not loaded
Scan PSR-4 entries for matching namespaces
Class name matches the namespace \ACME\App\Site (your first PSR-4 entry).
Load file app/View.php
File does not exist. Error.
It never goes back to step 3 and tries the next namespace.
So how do I fix it?
It looks like you want to separate your reusable library code from your site code. If that's the case, I would use separate namespaces. For example, use the ACME\Site namespace to hold your reusable code, and use ACME\MySiteName for your site-specific code. Then there will be no ambiguity, and composer will have no trouble loading your classes.
But I don't want to rearrange my namespaces!
Ok, that's fine, but you'll have to use a hack to get around your problem. Composer has a classmap loader, and you'll have to use that instead of the preferred PSR-4 loader.
{
"autoload": {
"classmap": ["app/", "src/"]
}
}
Let's separate the things a bit, because they are all mixed up for now.
What I am trying to do is this:
Have a core which can overwritten / extended.
The core is based off an interface.
This sounds like basic object oriented inheritance. An interface defines the proposed public behaviour, the core implements the needed basics, and the detail implementation changes some parts, and reuses the others.
Let's write your example code in a way PHP sees it with absolute namespace names:
class \ACME\App\Site\View\ViewExample extends \ACME\App\Site\View\View {}
class \ACME\App\Site\View\View extends \ACME\App\View\View {}
class \ACME\App\View\View {}
You have three classes explicitly named. You'd need three files that match the namespace and class name. The autoloading does not need to do any detection whether or not a class is present - because you cannot optionally inherit from a class that isn't there, or omit it otherwise.
On the other hand, implementing three levels of inheritance by default very likely is too much. It looks like bad design to me, and will make maintaining the code harder than necessary. Depending on what you want to achieve, there are plenty of alternatives to get what you want easier. For example, to change some details of behavior, there are the decorator pattern or the strategy pattern.
So what I really want to do is make it so I don't have to have site/app/View/View.php, and I don't have to have site/app/View/Example.php - it can use site/src/ACME/app/View/Example.php.
You cannot have this. Your code explicitly states that it inherits from \ACME\App\Site\View\View, so this class MUST be present somewhere.
This is independent of any autoloading. To experiment, you can add all your code into one single file and then run it. This will make all classes known to PHP immediately, and the problem will become obvious: You cannot remove a class when at the same time other classes inherit it.
Sorry I'm new to namespaces so I may not of phrased it very well.
Namespaces are nothing really fancy, the same problem would arise if you would use the PSR-0 style classnames with underscores:
class ACME_App_Site_View_ViewExample extends ACME_App_Site_View_View {}
// This class MUST be present for the above class to work
class ACME_App_Site_View_View extends ACME_App_View_View {}
class ACME_App_View_View {}
The main new feature with namespaces is that you can import one class under a second name within a file with use OtherNamespace\Classname. But this is only an alias within the scope of this file (i.e. it does not affect other files or the global scope).
Namespaces and autoloading are not the right tool for this job. A namespace is just a way of making sure two people (or parts of your code) don't use the same name to mean different things. Autoloading is just a way to avoid having to list every source file you want to load code from.
When you override the behaviour of one class in another, these are not the same class; often, you'll want to inherit the default actions and reuse parts of them.
You might want to create several sub-classes for different purposes, so you need somewhere to hold the logic of which to use. The component which deals with this is called a "service locator" or sometimes a "DI container".
Namespaces let you map short names to longer, unique class names; autoloading let's you map a specific unique class name to a source file; service location is how you choose which unique class you want to use in a specific circumstance.
I am new to using namespaces in PHP and they seem very simple. However, when I added a namespace to the top of a large file containing classes, interfaces, and closures, the code stopped working altogether. Apparently some elements are not qualified properly.
For example:
<?php
namespace MyNamespace;
interface MyInterface { ... }
class MyClass implements MyInterface { ... }
...
I read the documentation at php.net, but I couldn't find a simple list of elements that require qualification under a single named space (either globally or otherwise).
So my question is, if you simply declare a namespace at the top of an otherwise namespace-free file, what elements would require qualification in that scenario?
The way you have it now with everything in one file like that, every class, interface or function in that file is now in the MyNamespace namespace. So from within those classes, interfaces and functions, if you want to refer to a class that is in a different namespace (global or named) you must use it's fully qualified name (or use use statements to declare aliases at top of the file). Note: pre-pending a \ will get you to the global namespace.
Additionally, from outside of the file, if you want to access one of those classes, interfaces or functions you must use the fully qualified name.
MyNamespace\MyInterface
MyNamespace\MyClass
I should also mention, this is not a typical set up. According to psr standards, you should have only 1 class per file. Take a look at http://www.php-fig.org/ for more guidance on standards and practices.
I'm a beginner to L5. I read the documentation about extending classes but i didn't find any information about where to put the file in which i extend the class.
**I have to extend Str.php class. I have read that in L4 it had to be done by putting that file under App/folder but i didn't find that folder in L5.
So please can you tell me how can i do that?
This is the information i have now:
First, you must find where the class file is. We will be extending the Str class, which is under vendor/laravel/framework/src/Illuminate/Support. Note that you can also find this class under the aliases key in app/config/ app.php.
Now create a new folder called lib under app/folder. This folder will hold our class extensions. Because the Str class is grouped under the folder Support, it is suggested that you create a new folder named Support under lib too.
Now create a new file named Str.php under app/lib/Support, which you've just created:
But this is for L4
That's more of a general PHP question and there are two parts: 1) How to extend a class and 2) where to put files.
1) Extending classes isn't something Laravel or anyone else provides. That's right there in the language:
class A {}
class B extends A {}
As long as class A exists and is available, then class B can extend from it.
2) Where the files are is also important here. If you're defining class B and want to extend class A, the php runtime needs to know where to find A. Usually class A isn't defined in the same file as class B.
There are many ways to do this. You could require or include class A when you define class B. That would look something like:
a.php
class A {}
b.php
require "a.php";
class B extends A {}
Now with a lot of files like in the Laravel framework or any worthy library, you're going to have a lot of files to include and have to keep track of how to include those files. That's no fun. So, instead of doing that, PHP has provided a way to autoload the classes. That is, if you define classes in a predictable way, PHP can figure out what classes you're talking about without you having to use require or include statements.
There are also many ways of autoloading php files. In Laravel (and many, many other projects), the composer autoloader is used.
This means that files have to be placed in a pre-defined way in order for the composer autoloader to find them. By reading about the composer autoloader and then digging into the code to see how Laravel's classes are autoloaded, you'll be able to figure out how that happens.
Despite the intricate detail of Peter's answer, I figured I'd write something much more concrete: it doesn't matter.
If you check composer.json, you'll see that we are autoloading everything that is placed inside the app directory anyway. Hence, the choice is really yours. All that matters is that you maintain a sensible and readable structure. For example, you could place it in app/Lib, and namespace all your classes App\Lib (if App is your base namespace of course, which can be changed with php artisan app:name). Of course, you could also have a folder like Helpers/Lib for your extended classes, and keep some form of helpers.php with global helper functions in Helpers.
Why would you do this? Well, you might want to have an easy way to call your new Strfunctions, so instead of having to do Str::yourNewMethod($argument) everywhere, you could add a helper function yourMethod($argument) to easier call the function (if you intend to use it extensively).
One thing you have to remember though, as mentioned by Peter, is that the class you are extending won't automagically be found. It will, however, be autoloaded. Hence, to reference it you have to remember to namespace it, such as in the example below.
<?php namespace App\Helpers\Lib
Class Str extends \Illuminate\Support\Str {}
Also remember to namespace correctly when you call your own class.
I am using Vzaar's PHP Library for uploading videos from my website to their server space.
Now point is - in their library there are some PHP files in which more than one class exists and no class with same file name exists in same file.
i.e. have a look at OAuth.php, there is no class with name OAuth in that file.
Question raised in my mind is
When I create any PHP class file, can I create multiple classes in side one file, and later I can use that file in my code or I can use that reusable code in other project as well.
Should creating such files is good practice?
If the class is of 15 to 20 lines long, then should I create a separate file or I should include that in one file only, like OAuth.php.
Please guide with exact reason, if I will get links of wiki where proper explanation is given, then it will be best.
Putting more than one class in one file in general is a bad practice, and in Symfony2 even more because of the way class autoloader works.
When autoloader is looking for Acme\DemoBundle\SomeClass class it expects it will be in Acme\DemoBundle\SomeClass.php file. So in case you have a second class in the same file it won't work.
Check also PSR standards for class autoloading.
Despite I don't like to define more than one class per file I would like to point it out that PSR-4 is not against this practice if the class scope is private.
Quoting Symfony2 coding standards resource (http://symfony.com/doc/current/contributing/code/standards.html)
Define one class per file - this does not apply to private helper
classes that are not intended to be instantiated from the outside and
thus are not concerned by the PSR-0 and PSR-4 autoload standards;
In this other example (Thanks to Xavi Montero) you can see that the class Psr4AutoloaderClassTest has a helper class MockPsr4AutoloaderClass defined in the same file. So in general you should not, but for a "private helper" it's okey.
https://www.php-fig.org/psr/psr-4/examples
I'm searching for following issue i have.
The class file names of our project are named logon.class.php
But the interface file for that class is named logon.interface.php
My issue i have is that when the autoload method runs I should be able to detect if it is a class call or an interface call.
<?php
function __autoload($name){
if($name === is_class){
include_once($name.'class.php');
}elseif ($name === is_interface){
include_once($name.'interface.php');
}
}
?>
You can use ReflectionClass::isInterface to determine if the class is an interface.
$reflection = new ReflectionClass($name);
if ($reflection->isInterface()){
//Is an interface
}else{
//Not an interface
}
In your case, you would probably have to use file_exist first on $name.interface.php and $name.class.php to determine if they exist, require the one that exists, then check if it's an interface.
However, my opinion is that this might cause problems down the track. What if you have MyClass.class.php and MyClass.interface.php?
You should have some naming conventions for your classes and interfaces e.g. your class name is logon and interface name logon_interface, then you can easily differentiate between the two. For example, explode $name by underscore and check if last element is interface.
To avoid class name clashes you can use namespaces. Check The PSR-0 specifications.
Also check this post. If you read the contents of the file before including it, you can tokenize it and figure if the file contains an Interface or a class, without actually loading the class/interface. Keep in mind that interfaces and classes can't have the same name
Note: Using this method you can actually change the name of the interface at runtime (before loading the class, although that does seem very good practice)