Asked  8 Months ago    Answers:  5   Viewed   56 times

How could I call the constructor of a class with call_user_func_array

It is not possible to do :

$obj = new $class();
call_user_func_array(array($obj, '__construct'), $args); 

because if the constructor has parameters, the new will fail.

Constraint : I do not control the classes that I have to instantiate, nor can I modify them.

Don't ask me why I want to do this crazy thing, this is a crazy test.

 Answers

18

You can use reflection like:

$reflect  = new ReflectionClass($class);
$instance = $reflect->newInstanceArgs($args);

As of PHP 5.6.0, the ... operator can also be used for this purpose.

$instance = new $class(...$args);

if(version_compare(PHP_VERSION, '5.6.0', '>=')){
    $instance = new $class(...$args);
} else {
    $reflect  = new ReflectionClass($class);
    $instance = $reflect->newInstanceArgs($args);
}
Wednesday, March 31, 2021
 
iftheshoefritz
answered 8 Months ago
42

I think for now the only way to do what you want is:

class MyHelloWorld extends Base {

    use SayWorld {
        SayWorld::__construct as private __swConstruct;
    }

    public function __construct($a, $b, $c = 0)
    {
        $this->__swConstruct($a, $b, $c);
    }
}

Edit 2:

My advice, based on over a year of dealing with traits in PHP, is: avoid writing constructors in traits at all, or if you must - at least make them parameterless. Having them in traits goes against the idea of constructors in general, which is: constructors should be specific to a class to which they belong. Other, evolved high-level languages don't even support implicit constructor inheritance. This is because constructors have far more stronger relation to the class then other methods. In fact they have so strong relation, that even the LSP does not apply to them. The traits in Scala language (a very mature and SOLID-friendly successor of Java), can't have a constructor with parameters.

Edit 1:

There was a bug in PHP 5.4.11, which actually allowed to alias a superclass method. But this was considered a no-no by the PHP developers, so we are still stuck with that cumbersome solution which I presented above. But that bug raised a discussion about what can be done with this, and I'm hoping it will be targeted in future releases.

Meanwhile I came across the same problem over and over again. My irritation raised exponentially with the number of parameters and lines of docblock which had to be repeated a lot of times in order to use the trait. So I came up with the following pattern in order to stick to the DRY rule as much as I could:

Instead of repeating entire set of parameters like this:

trait SayWorld {

    /**
     * This is a valid docblock.
     *
     * @param int $a Doc comment.
     * @param int $b Doc comment.
     */
    public function __construct($a, $b) {
        echo (int)$c * ($a+$b);
    }
}

class MyHelloWorld extends Base {

    use SayWorld {
        SayWorld::__construct as private __swConstruct;
    }

    /**
     * Repeated and unnecessary docblock.
     *
     * @param int $a Doc comment.
     * @param int $b Doc comment.
     * @param int $c Doc comment.
     */
    public function __construct($a, $b, $c = 0)
    {
        $this->__swConstruct($a, $b);
    }
}

I write a class much like a tuple (concept familiar to C# and Python users), and use it instead of an endless list of parameters:

class SayWorldConstructTuple
{
    public $a;

    public $b;

    public function __construct($a, $b)
    {
        $this->a = $a;
        $this->b = $b;
    }
}

class MyHelloWorld extends Base {

    use SayWorld {
        SayWorld::__construct as private __swConstruct;
    }

    /**
     * New and valid docblock.
     *
     * @param SayWorldConstructTuple $Tuple
     * @param int $c Additional parameter.
     */
    public function __construct(SayWorldConstructTuple $Tuple, $c = 0)
    {
        $this->__swConstruct($Tuple->a, $Tuple->b);
        $this->c = $c;
    }
}

Note: this pattern is of course more useful with a larger amount of tuple's constructor parameters, and more classes using the tuple.

It can be automated further with the use of PHP's dynamic nature.

Wednesday, March 31, 2021
 
francadaval
answered 8 Months ago
82

set_error_handler is designed to handle errors with codes of: E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE. This is because set_error_handler is meant to be a method of reporting errors thrown by the user error function trigger_error.

However, I did find this comment in the manual that may help you:

"The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called."

This is not exactly true. set_error_handler() can't handle them, but ob_start() can handle at least E_ERROR.

<?php

function error_handler($output)
{
    $error = error_get_last();
    $output = "";
    foreach ($error as $info => $string)
        $output .= "{$info}: {$string}n";
    return $output;
}

ob_start('error_handler');

will_this_undefined_function_raise_an_error();

?>

Really though these errors should be silently reported in a file, for example. Hopefully you won't have many E_PARSE errors in your project! :-)

As for general error reporting, stick with Exceptions (I find it helpful to make them tie in with my MVC system). You can build a pretty versatile Exception to provide options via buttons and add plenty of description to let the user know what's wrong.

Wednesday, March 31, 2021
 
SJain
answered 8 Months ago
21

Indeed you are correct. Nothing can be done with the return value of a constructor (aside from using the Object it created).

So no, you aren't missing anything, it's the developer who wrote that code who is.

It is technically possible to use return values from constructors, if you call the function directly

$obj->__construct();

That would allow you to use the constructor's return value. However, that is highly uncommon and fairly not recommended.

Friday, June 25, 2021
 
saad
answered 4 Months ago
22

As I understand this, in PHP4 my code was buggy, but not in PHP7, right?

Not quite. PHP4-style constructors still work on PHP7, they are just been deprecated and they will trigger a Deprecated warning.

What you can do is define a __construct method, even an empty one, so that the php4-constructor method won't be called on a newly-created instance of the class.

class foo
{
    public function __construct()
    {
        // Constructor's functionality here, if you have any.
    }

    public function foo()
    {
        // PHP4-style constructor.
        // This will NOT be invoked, unless a sub-class that extends `foo` calls it.
        // In that case, call the new-style constructor to keep compatibility.
        self::__construct();
    }
}

new foo();

It worked with older PHP versions simply because constructors don't get return value. Every time you created a Participant instance, you implicitly call the participant method, that's all.

Wednesday, July 21, 2021
 
relyt
answered 4 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share