Open someniatko opened 2 years ago
I found these snippets:
I was trying to setup Psalm on a codebase that's already using PHPStan (I figured it would be good to check things with both tools), and this is one of the main things blocking me from doing so. I have several abstract classes that define template types used in the params of their static methods. For (an abridged) example:
/**
* @template T of Table
* @template R of array<non-empty-string, mixed>
*/
abstract class Model {
/**
* @phpstan-param R $row
*
* @phpstan-return self<T, R>
*/
abstract public static function fromRow(array $row): self;
}
The param type of the fromRow
method causes Psalm to complain Docblock-defined class, interface or enum named My\Namespace\R does not exist
.
I confirm the issue and join the request of how to do templating for static properties. The minimal case of reproduction is attached below. https://psalm.dev/r/9a4c417e38
I found these snippets:
@orklah Do you think introducing something like @static-template
or @template-static
may solve the issue? (and @template-static-implements
, @template-static-extends
)
Possibly. Frankly, this is kinda over my head. It's a design choice that was made before I started actively contributing and I would have no idea how to change that meaningfully
This also affects static properties as seen in https://psalm.dev/r/047cddc9ac.
Having a static template annotation won't help when we have mixed usage I suppose (storing values from static context but using them in instanced context).
I found these snippets:
I try to design something like this: https://psalm.dev/r/4cf10dedf9
However, as stated by @orklah in https://github.com/vimeo/psalm/issues/7507#issuecomment-1024437536,
Is there a way to design the interface in such a way Psalm won't complain?