Deprecation warnings "Non-static method should not be called statically" after upgrading to v6.3.0

[ChrisTitos]

Hi,

We use PHP-DI in combination with Silly and since upgrading to PHP-DI 6.3.0 we get these kind of warnings when running CLI commands:

PHP Deprecated:  Non-static method system\testset\DataLoadCommand::loadChannels() should not be called statically in /var/www/html/vendor/php-di/invoker/src/Reflection/CallableReflection.php on line 19

This is the command definition:

$app->command(
    'setupCompanies:loadChannels',
    [\system\testset\DataLoadCommand::class, 'loadChannels']
);

It does still seem to work fine though, it only seems to be a notice.

I guess this is a bug in Invoker but since we do not explicitly depend on that ourselves I thought I'd make the issue in this project. I can add this issue in that project as well if you prefer.

[SvenRtbg]

Well, you are giving the class name and the method name. If no magic happens somewhere else (reading the docs for silly, I think there is no magic), then this array (first element a string with a classname, second element a string with a method name) is a callable resolving into a static call.

If you really need an instance of DataLoadCommand, you'd somehow create that first. For example make the first element of that array contain the instance you want to use instead of the class name string.

Otherwise you may also switch the loadChannels method to be static, if it is working that way.

[mnapoli]

Hi thanks for the report. It does sound like a bug though 🤔

I will be assuming that you setup PHP-DI with Silly and that:

• either you configured the DataLoadCommand class in the container config
• or you did not disable autowiring

What PHP-DI should do (expected behavior) is detect that loadChannels is to a static method, and resolve DataLoadCommand from the container and call the method on the object.

For some reason there may be a regression here.

[mnapoli]

If you did configure DataLoadCommand could you show the config?

[ChrisTitos]

I have autowiring enabled so I did not configure the command manually.

Indeed PHP-DI still seems to work properly, the method gets called, it's just this warning that now shows up. I have multiple commands like this configured and every time I run any CLI command I get a warning for each of those commands.

[ChrisTitos]

We were still using Symfony v4 components in our codebase, and after upgrading everything to v5.* the deprecation warnings also seemed to disappear.
Don't know if it was the actual cause, but at least I don't have this problem anymore :).

[ChrisTitos]

Sorry I spoke too soon. I thought it was working, but it was only working because Invoker 2.1.0 was still in my composer.lock file. When it updated to 2.2.0 again I got the same errors again.

[mnapoli]

Ideally if you're able to show how to reproduce that with a minimal example that would be great.

[ChrisTitos]

Setting error_reporting to all gives you the deprecation notice even with a minimal setup:

<?php
error_reporting(E_ALL);

require __DIR__ . '/vendor/autoload.php';

$app = new Silly\Edition\PhpDi\Application();

$app->command('test', [\Chris\Test\Foo::class, 'bar']);

$app->run();

<?php

namespace Chris\Test;

use Symfony\Component\Console\Output\OutputInterface;

class Foo
{
    public function bar(OutputInterface $output)
    {
        $output->writeln('Test');
    }
}

It doesn't give the deprecation notice with Invoker 2.1

[ChrisTitos]

Looking into this a bit more, by removing the "callable" type hint in CallableReflection::create the notice seems to be gone. But that's weird since the callable seems to be valid (even in PHP8)

The callable before it's resolved:

Invoker.php:45:
array(2) {
  [0] =>
  string(14) "Chris\Test\Foo"
  [1] =>
  string(3) "bar"
}

The callable after it's resolved:

Invoker.php:58:
array(2) {
  [0] =>
  class Chris\Test\Foo#90 (0) {
  }
  [1] =>
  string(3) "bar"
}

The string gets correctly replaced with the class instance.. and that should be a valid callable? Yet the deprecation notice is triggered.

[mnapoli]

This should be fixed by upgrading php-di/invoker.

Let me know if the problem is still there.