Hi, would you care to rewrite this as a new NodeScopeResolverTest::testFileAssert's dataProvider? It would be much clearer to see assertType('false', 1.9 > 2.1) instead of jumping between this file and rule test. Thanks!

Sure thing.

Done.

As a future scope, we should probably think about rewriting this as a method on Type. That way, we could also write implementation of == and also nicely write implementation between different ConstantArrayTypes for example.

Remember, I want to deprecate and get rid of most instanceof *Type. But I'll merge this PR as it is once the other comment is resolved :)

Thank you!

Right! Actually, I can try to have a go at this tomorrow. So it would be a new method smallerThan() and smallerThanOrEqualTo() method on Type?

public function smallerThan(self $otherType): TrinaryLogic;
public function smallerThanOrEqual(self $otherType): TrinaryLogic;

Most of these method implementations have a special if condition for CompoundType which are implemented by special types like UnionType or IntersectionType, it might look like this:

	public function accepts(Type $type, bool $strictTypes): TrinaryLogic
	{
		if ($type instanceof static) {
			return TrinaryLogic::createYes();
		}

		if ($type instanceof CompoundType) {
			return $type->isAcceptedBy($this, $strictTypes);
		}

		return TrinaryLogic::createNo();
	}


	public function isSuperTypeOf(Type $type): TrinaryLogic
	{
		if ($type instanceof self) {
			return TrinaryLogic::createYes();
		}

		if ($type instanceof CompoundType) {
			return $type->isSubTypeOf($this);
		}

		return TrinaryLogic::createNo();
	}

It's there so that each type can only show interest in types that it should care about. All of these CompoundTypes are handled by a single if in most ordinary Type implementations which makes things easier. I don't know how to name the relevant CompoundType method, maybe isGreaterThan, as an inversion similar to accepts/isAcceptedBy? :) You'll see...

Please see the update, I hope it is somewhat how you intended it to be. I opted to only add one method, since in almost all implementations < and <= can be handled with the same code. If desired I could still add isSmallerThanOrEqual(), which would then just call isSmallerThan(..., ..., true).

Also I added the is prefix to the method names (IMHO method names should always include at least one verb). This makes it also more similar to a probable future isEqualTo(), which needs to be clearly distinguished from equals().

Finally, I made IntegerRangeType implement CompoundType, I hope that makes sense, because it really needs to handle isGreaterThan().