BTW I have a small thing to ask - please use first letter upper-case in your PR titles and commit messages.

starting with my next PR, I will take this into account.

This pull request has been marked as ready for review.

Small thought for ConstantInteger, ConstantString, ConstantBoolean, ...

Rather than methods isConstantInteger on so on, did you think/do you plan to create isConstant since you'll already have isInteger, isBoolean, isString, ... , :)

Rather than methods isConstantInteger on so on, did you think/do you plan to create isConstant since you'll already have isInteger, isBoolean, isString, ... , :)

these types can already be checked with the ConstantScalarType interface, so I think there is currently no need to have them on Type again

@VincentLanglet I think a method like Type::getConstantStrings(): list<ConstantStringType> makes the most sense.

But integers complicate it a bit. I don't know how getConstantIntegers should be implemented in IntegerRangeType, I don't want huge arrays. Maybe we'll have to treat integers in a different way.

Rather than methods isConstantInteger on so on, did you think/do you plan to create isConstant since you'll already have isInteger, isBoolean, isString, ... , :)

these types can already be checked with the ConstantScalarType interface, so I think there is currently no need to have them on Type again

I thought the purpose of all those methods were to get rid of all the instanceof checks.
So how do you get rid of the instanceof check in (one of you current diff)

($returnType->isNull()->yes() || $returnType instanceof ConstantBooleanType)

?

ondrej has a better idea of it, I am pretty sure.

I thought the purpose of all those methods were to get rid of all the instanceof checks.

I think we are getting rid of instanceof X while X is a concrete type class. I am not sure we need to get rid of it when X is an interface.

@VincentLanglet There's already Type::isTrue(): TrinaryLogic and Type::isFalse(): TrinaryLogic.

@staabm We want to get rid of instanceof Constant*Type too because very often people just do $type instanceof ConstantStringType and it doesn't occur to them they should handle 'foo'|'bar' as well.

Thank you!

good, then there's still work left for me 😅

@herndlm There's ton of work to be done, I'm looking forward to get rid of instanceof TypeWithClassName 😊 And there's a lot more.

I know that there's no need to be worried hehe. great that multiple people are now actively cleaning up!

Also SubtractableType, that's gonna be a lot of fun 😂

We want to get rid of instanceof Constant*Type too because very often people just do $type instanceof ConstantStringType and it doesn't occur to them they should handle 'foo'|'bar' as well.

i ran into this exact case last week in a custom rule 😅