Is this package equivalent to a Psalm stub?

[Ocramius]

See https://github.com/laminas/laminas-inputfilter/blob/11080cf5a67fd2368d31b50e28403fb21cbf2f14/.stub.php

Copying it here for reference:

<?php

declare(strict_types=1);

namespace Psr\Container {

    interface ContainerInterface
    {
        /** @param string|class-string $name */
        public function has(string $name): bool;

        /**
         * @template T of object
         * @psalm-param string|class-string<T> $name
         * @psalm-return ($name is class-string ? T : mixed)
         */
        public function get(string $name): object;
    }
}

Usage:

<?php

class Thing {
    public function doStuff(): void
    {
    }
}

/** @psalm-var ContainerInterface $container */

$value = $container->get(Thing::class);
$value->doStuff();

See https://psalm.dev/r/027e9ad09e

Is this package comparable to that? What differences does it bring to that approach, and is a stub sufficient?

Ref: https://github.com/laminas/laminas-inputfilter/pull/53#discussion_r891112567

[Lctrs]

I think it should be comparable. Best way to be sure is to replace the checker by your stub and run the integration suite :)

[Ocramius]

Heh, we just introduced it, so no difference: this is mostly to understand if such a stub makes the plugin superfluous :D

[Lctrs]

Maybe one difference I see is that the checker is able to check for plain string. But I don't think that you'll care about it.

[gsteel]

One drawback to using a stub is that PHPStorm picks it up and marks everywhere you use a ContainerInterface with a multiple implementation warning, not only in the library hosting the stub, but also anywhere you install the library as a dependency.

[Ocramius]

Instead of .stub.php, call it .php.stub and you are good ;-)

[gsteel]

Good idea! Or export-ignore it in .gitattributes