Use isArray instead of array supertype checks

[herndlm]

another small (got bigger over time..) refactor. I'll stop now.. :)

UPDATE: added another commit that does the same for isString

[herndlm]

I was not expecting that one additional failure. weird. needs some debugging..

[staabm]

one more here

phpstan-src/src/Analyser/TypeSpecifier.php

Line 529 in ed6548c

($stringType->isSuperTypeOf($leftType)->yes() && $stringType->isSuperTypeOf($rightType)->yes())

[ondrejmirtes]

Please ping me once you mark this as ready, I'm looking forward to merge this.

[herndlm]

I think in order to be able to continue here I'd need #1644 to avoid weird behaviour or exceptions

[herndlm]

@ondrejmirtes this is ready now. I could create isInteger next and do the same if you like that

[ondrejmirtes]

Yeah, you could be the guy who spends the next 6 months painstakingly creating methods on Type interface for all the use cases where we currently use instanceof *Type and TypeUtils methods :) That would be really awesome if it sounds interesting to you :)

[ondrejmirtes]

Thank you!

[herndlm]

Yeah, you could be the guy who spends the next 6 months painstakingly creating methods on Type interface for all the use cases where we currently use instanceof *Type and TypeUtils methods :) That would be really awesome if it sounds interesting to you :)

you need to work on your sales pitch :D
I don't want to promise much, but I'll definitely continue with some primitive type methods. Feel free to mention any methods you're interested in

[ondrejmirtes]

It's not my fault there's "pain" in "painstakingly" 🤣

[ondrejmirtes]

Another easy one should be to replace stuff like instanceof TypeWithClassName, instanceof ObjectType, TypeUtils::getDirectClassNames().

[herndlm]

AFAIK the problems with instanceof replacements are then that methods are not guaranteed to exist on the Type interface, right? E.g. it's not safe anymore to call getClassName() on the potential union :/

ah and I misread "painstakingly" with "painfully" yesterday I guess. Both are fitting terms I think :D

[ondrejmirtes]

This is the problem I'm trying to solve - there needs to be methods for EVERYTHING directly on Type. It nicely solves issues when the type is UnionType etc.

[herndlm]

definitely, yeah. it would also surely help with some constantarray operations I think and then greatly simplify the code that currently needs conditionals to deal with them with the downside of blowing up the Type interface I guess. but for the array/constantarray methods there could be a trait that implements the array-specific methods once for all non-array types or so and then maybe it's not a big deal after all

[ondrejmirtes]

What we can do once the transformation is complete is to remove all specific Template*Type implementations and have just one TemplateType (class!) that supports any bound.

We can also stop inheriting type classes from each other.

And I guess we could also have a general SubtractableType that supports any type.