I'm just starting out learning PHPUnit. I have a seemingly very simple test;
namespace stats\Test;
use stats\Fetch;
class FetchTest extends \PHPUnit_Framework_TestCase
{
public function setUp()
{
$this->fetch = new Fetch;
}
public function testStoresListOfAssets()
{
$this->assertClassHasStaticAttribute('paths', 'Fetch'); //line 17
}
}
My Fetch class is;
namespace stats;
class Fetch
{
public static $paths = array(
'jquery' => 'http://code.jquery.com/jquery.js'
);
}
The error I get when running PHPUnit;
PHPUnit_Framework_Exception: Argument #2 (string#Fetch)of PHPUnit_Framework_Assert::assertClassHasStaticAttribute() must be a class name
It's probably something very silly but I can't understand the problem
The PHPUnit_Framework_Assert use the PHP method class_exists to check if the classname you have indicated is correct (check this link to see the full code):
if (!is_string($className) || !class_exists($className, FALSE)) {
throw PHPUnit_Util_InvalidArgumentHelper::factory(2, 'class name');
}
The problem you have here is the method class_exists doesn't take into account this command:
use stats\Fetch;
So that, you have to indicate the full path to make it work. In this link of stackoverflow you can find more information about that problem. You should change your assert to something like this:
$this->assertClassHasStaticAttribute('paths', '\\stats\\Fetch');
You're not supplying the fully qualified class name and in the context of assertClassHasStaticAttribute() or any other method/function outside of the scope of your (test) class the use statement that complements the class name.
If you're using PHP 5.5 or later (which you should ;) use Fetch::class.
In general you should prefer ::class over strings for class names as modern IDEs can help you with refactoring when changing class names which is close to impossible if you use strings.
To sum it up, for your example it would be:
public function testStoresListOfAssets()
{
$this->assertClassHasStaticAttribute('paths', Fetch::class);
}
Related
When I create a class object dynamically I don't understand why it throws class not found. However, if I will remove namespace App\Controls and use App\Controls\one, it worked perfectly example code:
namespace App\Controls;
use App\Controls\one;
class one {
public static function test_one($className, $object) {
return $object((new $className));
}
}
class two {
public function language($lang) {
echo 'I love '.$lang;
}
}
one::test_one('two', function($table) {
$table->language('PHP');
});
from this structure I want to call class two depends on the value I input. I also include use App\Controls\two but still not working, but that's not the case because supposedly I will not add another use App\Controls\className just to call create another class object and it's not possible from PHP.
In PHP, namespaces are resolved when the code is compiled, not when it is run.
So, when you write this:
namespace MyNamespace;
use MyOthernamespace\SomeClass;
$foo = new Foo;
$bar = new SomeClass;
The compiler looks at the current namespace, and the class names you've "imported", and compiles the code as though you'd written this:
$foo = new MyNamespace\Foo;
$bar = new MyOthernamespace\SomeClass;
(Note that you don't need to use anything in the current namespace; that's assumed as the default prefix for everything.)
In your code, the compiler doesn't know that the 'two' is going to be used as a class name, so it doesn't change it; so when the dynamic code runs, it comes out literally as:
return $object((new two));
Which won't work - there isn't a class called two, only one called App\Controls\two.
The solution to this is the magic ::class syntax, which tells the compiler to expand something like it would for a class name, and then turn it into a string. It's important to know that despite the name, it doesn't actually care if the thing it's expanding is a class, or exists at all, it just expands it and assumes you know what you're doing with it.
So if you write this:
namespace App\Controls;
one::test_one(two::class, function($table) {
$table->language('PHP');
});
It will be expanded by the compiler to this:
App\Controls\one::test_one('App\Controls\two', function($table) {
$table->language('PHP');
});
Then when it gets into the dynamic code, it will be referencing the right class name, and run the code as though it was this:
return $object((new App\Controls\two));
I am trying to alias a static method from a utility/helper class, the documentation does not give anything regarding static methods and using those defined there doesn't work for static methods (as it seems so).
So say I have this class:
namespace App\Helpers;
class HTTP {
public static function extract_path_from_url( string $url ) {
$parsed_url = wp_parse_url( $url );
if ( ! isset( $parsed_url['path'] ) ) {
return false;
}
return (string) $parsed_url['path'];
}
}
then trying to use it on a different file:
<?php
echo \App\Helpers\HTTP::extract_path_from_url( 'http://example.com/test' );
that one above works
but trying to alias it:
<?php
use \App\Helpers\HTTP\extract_path_from_url as extract_path;
echo extract_path( 'http://example.com/test' );
would output
Fatal error: Uncaught Error: Call to undefined function App\Helpers\HTTP\extract_path_from_url()
even:
<?php
use \App\Helpers\HTTP::extract_path_from_url as extract_path;
echo extract_path( 'http://example.com/test' );
shows this weird error:
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM)
Is this possible?
Regards,
Aliasing doesn't magically convert methods into functions, try this instead
<?php
use \App\Helpers\HTTP as extract_path;
echo extract_path::extract_path_from_url( 'http://example.com/test' );
Also (it should go without saying) when you alias this only affects the namespace and class name, not methods of the class. These are generally used for 1 of 2 things. Resolving naming conflicts
use NamespaceOne\Someclass;
use NamespaceTwo\Someclass as SecondClass;
If these were both put without an alias then using
Someclass::method()
Would be ambiguous.
The second thing they can be used for is if you need a lot of classes imported from one namespace. Such as this:
use App\Exceptions\NoFile;
use App\Exceptions\FileSize;
use App\Exceptions\FileType;
throw new NoFile();
throw new FileSize();
throw new FileType();
Can be done this way:
use App\Exceptions as E;
throw new E\NoFile();
throw new E\FileSize();
throw new E\FileType();
Which is not only shorter, but easier to maintain if you change the namespace you have to only change it for the alias and then all is good. So in short it's not really intended for what you want to use it for.
Wrap it
You can always make a wrapper for it:
if(!function_exists('extract_path_from_url')){
function extract_path_from_url($url){
return \App\Helpers\HTTP::extract_path_from_url($url);
}
}
And then call it to your hearts content. Performance wise you do have an extra call by wrapping it, but generally wrappers make it easier to maintain. For example if you rename that method or class, you can change it in the wrapper and everything is good. So there is an argument to be made for either option.
You don't have to check if the function exists, but depending on how your overall system works it may not be a bad idea, so I included it in the example just for the sake of completeness. Personally in a case like this, I don't see any issue putting it right in the same file with the class, just remember to load it. If you are using autoloading the functions won't be included unless you manually load the file or otherwise force it to autoload. Assuming nothing else uses the class first, of course.
One method I have used in the past that I really like, is to make a file named http_functions (classname + _functions) and then add a static method to the class that registers the functions:
class HTTP {
public static function regester_fuctions(){
require 'http_functions.php'
}
}
Then when you call HTTP::regester_fuctions() it autoloads HTTP class and includes all the functional wrappers. In fact I do this very thing in my really super awesome debug print class (queue shameless plug) https://github.com/ArtisticPhoenix/Debug
Just some thoughts, enjoy!
A workaround is to use a namespaced helpers.php file and define 'simple' functions in it, which simply pass through arguments.
// lib/My/Deeply/Nested/Namespace/MyClass.php
<?php
namespace My\Deeply\Nested\Namespace;
class MyClass
{
public static function aVeryUsefulFunction(string $var): string
{
// ...Do some stuff
return $magic;
}
}
// lib/helpers.php
namespace App;
use My\Deeply\Nested\Namespace\MyClass;
function doMagic(...$args)
{
return MyClass::aVeryUsefulFunction(...$args);
}
// templates/my-view.php
<?php use function App\doMagic; ?>
<div>I am doing <?= doMagic('magic') ?>!</div>
Note that by using the spread operator ...$args in my 'pass through' function I can change the requirements of the 'target' function without having to update it in two places.
This will break IDE completion, as it will only know to suggest ...$args rather than string $var. I don't know of a way to docblock a function to tell it to read parameters from another function.
As manual says you can import via use classes, functions and constants. Method of a class (even a static one) is not a function.
So, for example you have:
namespace My\Super\NameSpace;
const MY_CONST = 42;
class MyClass {
public function do() { /* code */ } // this is NOT a function
public static function doStatic() { /* code */ } // this is NOT a function too
}
function my_function() { /* code */ } // this is function
In some other file you can write:
namespace YaNamespace;
use const My\Super\NameSpace\MY_CONST;
use My\Super\NameSpace\MyClass;
use function My\Super\NameSpace\my_function as func_alias;
And that's all items you can import with use.
Code speaks better than words:
namespaces.php:
<?php
namespace foo;
use foo\models;
class factory
{
public static function create($name)
{
/*
* Note 1: FQN works!
* return call_user_func("\\foo\\models\\$name::getInstance");
*
* Note 2: direct instantiation of relative namespaces works!
* return models\test::getInstance();
*/
// Dynamic instantiation of relative namespaces fails: class 'models\test' not found
return call_user_func("models\\$name::getInstance");
}
}
namespace foo\models;
class test
{
public static $instance;
public static function getInstance()
{
if (!self::$instance) {
self::$instance = new self;
}
return self::$instance;
}
public function __construct()
{
var_dump($this);
}
}
namespace_test.php:
<?php
require_once 'namespaces.php';
foo\factory::create('test');
As commented, if I use the full-qualified name inside call_user_func() it works as expected, but if I use relative namespaces it says the class was not found – but direct instantiations works. Am I missing something or its weird by design?
You have to use the fully qualified classname in callbacks.
See Example #3 call_user_func() using namespace name
<?php
namespace Foobar;
class Foo {
static public function test() {
print "Hello world!\n";
}
}
call_user_func(__NAMESPACE__ .'\Foo::test'); // As of PHP 5.3.0
call_user_func(array(__NAMESPACE__ .'\Foo', 'test')); // As of PHP 5.3.0
I believe this is because call_user_func is a function from the global scope, executing the callback from the global scope as well. In any case, see first sentence.
Also see the note aboveExample #2 Dynamically accessing namespaced elements which states
One must use the fully qualified name (class name with namespace prefix).
In current versions of PHP, the way you have it is the way it is -- when using a string to reference a classname, it needs to be fully qualified with it's complete namespace. It's not great, but that's the way it is.
In the forthcoming PHP v5.5, they will include a feature to address this, by providing a new Classname::class syntax, which you can use instead of putting the FQN classname in a string.
For more info on this, please see the relevant PHP RFC page here: https://wiki.php.net/rfc/class_name_scalars
Your code would look something like this:
return call_user_func([models\$name::class,"getInstance"]);
That may not be exact; I don't have a copy of 5.5 to test with to confirm. But either way, the new syntax will make things a lot better for use cases like yours.
If you try using class_exists() inside a method of a class in PHP you have to specify the full name of the class--the current namespace is not respected. For example if my class is:
<?
namespace Foo;
class Bar{
public function doesBooClassExist(){
return class_exists('Boo');
}
}
And Boo is a class (which properly autoloads) and looks like this
namespace Foo;
class Boo{
// stuff in here
}
if I try:
$bar = new Bar();
$success = $bar->doesBooClassExist();
var_dump($success);
you'll get a false... is there an alternative way to do this without having to explicitly specify the full class name ( i.e. class_exits('Foo\Boo') )?
Prior to 5.5, the best way to do this is to always use the fully qualified class name:
public function doesBooClassExist() {
return class_exists('Foo\Boo');
}
It's not difficult, and it makes it absolutely clear what you're referring to. Remember, you should be going for readability. Namespace imports are handy for writing, but make reading confusing (because you need to keep in mind the current namespace and any imports when reading code).
However, in 5.5, there's a new construct coming:
public function doesBooClassExist() {
return class_exists(Boo::class);
}
The class pseudo magic constant can be put onto any identifier and it will return the fully qualified class name that it will resolve to.......
Example in file 1:
namespace A;
class Foo{
}
file 2:
use A\Foo;
do_stuff('A\Foo'); // <- need namespace here :(
Foo::someStaticMethod(); // <- namespace not required :D
Is there any way I can pass class names in function arguments like constants or something, so I don't need to prepend the namespace?
Update :)
When I know, that I need to pass the classnames of some classes around as string I'm used to create special class constant
namespace Foo\Bar;
class A {
const __NAMESPACE = __NAMESPACE__;
const __CLASS = __CLASS__;
}
Now you can reference the classname like
use Foo\Bar\A as Baz;
echo Baz::__CLASS;
With PHP5.5 this will be builtin
echo Baz::class;
Full-Qualified-Names (FQN) for namespaces always starts with a namespace separator
do_stuff('\A\Foo');
except (and thats the only exception) in use-statements, because there can only appear complete namespace identifiers, so for convenience you can omit it there.
However, a string is a string and where you use it as a class name is out of scope of the interpreter, so it lost the reference to the former use A\Foo-aliasing. With PHP5.5 you can write Foo::class, but I think thats not an option right now ;)
You could instantiate a new object, then call get_class() to get the fully qualified name for the class.
use A\Foo;
$foo = new Foo();
do_stuff(get_class($foo)); // get_class($foo) = '\A\Foo'
This means that the namespace of Foo is only defined by the use statement (ie. less code maintenance).
Or you can pass class reflection.
ReflectionClass
No, not without tracing the caller, as far as I know. The function you are calling must exists within the same namespace as the object you are trying to pass.
You might want to have a look at the debug_backtrace function if you require the namespace resolution. But this requires the file-paths to be translated into namespace resolutions or similar.
This is however possible: (I see Andrew has answered with the same type of solution.)
function doStuff ($obj)
{
$name = (is_object($obj))
? (new ReflectionClass(get_class($obj)))->getName()
: $obj;
// $name will now contain the fully qualified name
}
namespace Common;
class Test
{}
$testObj = new Test();
// This will work, but requires argument to be
// fully quialified or an instance of the object.
\doStuff($testObj);
\doStuff("\Common\Test");