Add Assert::implementsInterface

[boesing]

No description provided.

[ondrejmirtes]

Thank you! Will tag it promptly.

[mamazu]

Nice pull request however this doesn't work in the case where both arguments are strings which the assert function allows.

[ondrejmirtes]

Yes, AFAIK PHPStan does not understand $object instanceof $class so it should be fixed there.

[mamazu]

Yeah I would also go with the class_implements approach like this:

return new \PhpParser\Node\Expr\FuncCall(
    new \PhpParser\Node\Name('in_array'),
    [
        $class,
        new \PhpParser\Node\Expr\FuncCall(new \PhpParser\Node\Name('class_implements'), [$expr]),
    ]
);

[ondrejmirtes]

I’m not sure there’s class_implements dynamic return type extension in PHPStan and that this would work...

[mamazu]

True.

[mamazu]

But the only thing that phpstan could optimize for are two cases:

1. Both values are "constant" strings then the assertion doesn't make sense (either it always throws or never throws)
2. If the object implements the interface by type hint. For all other cases there shouldn't be any optimization.

But instanceof doesn't work if both arguments are strings.

[melkamar]

Hi, PHPStan is reporting errors where it should not when upgrading to this version. The following code is, imo, correct:

class FilterDefinition
{
    /* @var string */
    private $filterClass;

    /**
     * @param string $filterClass FQCN of a filter class. The string must be a PHP class which implements the {@see FilterInterface}
     */
    public function __construct(string $filterClass)
    {
        Assert::implementsInterface($filterClass, FilterInterface::class);

        $this->filterClass = $filterClass;
    }
}

Instances of FilterDefinition are used in some factory methods and I need to ensure that the provided class (not instances of the class!) implements the FilterInterface. So the Assert::implementsInterface() makes sense here, yet PHPStan yells at me with

Call to static method Webmozart\Assert\Assert::implementsInterface() with string and 'RH\\CoreBundle…' will always evaluate to false. 

Any suggested workaround, other than fixing the version to 0.11.2?

[mamazu]

Yeah that's the same issue I also tried to fix in my merge request. But the quick fix would be to create an object of that class, which is probably not really a possible solution.

[melkamar]

I see. No, instantiating the class is not an option here, so I'll have to downgrade.

Just wanted to add the comment here for visibility, that this issue affects someone else as well :)