Template references in the same class

[dpi]

As referred by #17 (comment)

The library doesn't know what to do about template references in the same class, as in:

https://phpstan.org/r/9f0ab119-cd14-47f0-8a5a-ac8cb69f3b6c

The last three examples here have Generic<T> where T is defined in the same class.

---

/**
 * @template T
 */
class A {
	/**
	 * @return T
	 */
	public function m() {
		// @phpstan-ignore-next-line
		return '';
	}
}

/**
 * @extends A<Z>
 * @template Z of int
 */
class C extends A {}

Library thinks m() returns a Z, instead of int.

[autaut03]

This is indeed another bug - but quite fixable. The result though wouldn't be exactly what you expected.

Taking your PHPStan example:

• class C (@template Z of int) should actually return T template type - reflection shouldn't discard template types that weren't provided; this may be useful by itself
• class D (@template Z of int|string|float) should also return T
• class E (@template Z of int|string|float = string) should return string and be identical to $reflector->forType(E::class, [PrimitiveType::string()])

The last case is trivial to fix, I'll get to it soon. And while yes, PHPStan reports the "resolved" types instead of T in the first two cases, I believe that's just because of how dumpType() works - it's in the context of executing code, not reflecting it.

I need to verify this, but I believe that if you were to access the actual return type through PHPStan's internal reflection, you'd get T of int|string|float, not just int|string|float. But I may be wrong here.

I'll take a look and think on how I can provide a better type system so you would be able to tell that m returns int one way or the other.

[autaut03]

One possibility is that m would be returning T & int (of course, only in cases without = string default) - that kind of makes sense to me.

Could you also expand on your real life use case here? In my practice I never needed to reflect a generic class without providing all of its type parameters, so I don't know what API you would expect

[dpi]

The (almost) real example is:

/**
 * @template T of Thing1|Thing2|Thing3 = Thing1|Thing2|Thing3
 * @extends \Ramsey\Collection\AbstractCollection<T>
 */
class Things extends AbstractCollection {

Later:

$rClass = $this::$reflector->forType(Things::class);
$rClass->method('offsetGet')?->returnType(); # T, but I expect Thing1|Thing2|Thing3
$rClass->method('offsetSet')?->parameter('value')?->type(); # T, but I expect Thing1|Thing2|Thing3

[autaut03]

/**
 * @template T of Thing1|Thing2|Thing3 = Thing1|Thing2|Thing3
 * @extends \Ramsey\Collection\AbstractCollection<T>
 */
class Things extends AbstractCollection {

But if it's a collection of things, shouldn't it then be:

/**
 * @extends \Ramsey\Collection\AbstractCollection<Thing1|Thing2|Thing3>
 */
class Things extends AbstractCollection {

? And I'm more interested in this case:

/**
 * @extends A<Z>
 * @template Z of int
 */
class C extends A {}

E.g. one without the default parameter value

[dpi]

But if it's a collection of things, shouldn't it then be:

the template is used in a method unique to the class in context. So its just DRY.

And I'm more interested in this case:

After testing a bit more, the problem may only lie with not knowing what to do with template default values.

[autaut03]

Template defaults fixed in #34.

I'm leaving the issue open as there's still an issue with type being Z, instead of the expected T. And there's still the question of how to (and whether to) represent T of string types

[dpi]

Template defaults seems to work well in my limited testing, I have what I need for this issue.

Thanks!