Introduce isSuperTypeOfWithReason

[VincentLanglet]

As suggested by #3536 (comment)

[VincentLanglet]

I dunno if it makes sens to have a negate method (Should the reasons be lost ?)

I created one since I had multiple Trinary::negate calls to replace.

[VincentLanglet]

Here we're loosing a lazyOr into a or.

I dunno if the lazy could be kept on AcceptsResults but I saw similar lazy lost when isAcceptedWithReasonBy was introduced

[VincentLanglet]

Here we're loosing a lazyAnd into a and.

I dunno if the lazy could be kept on AcceptsResults but I saw similar lazy lost when isAcceptedWithReasonBy was introduced

[VincentLanglet]

Here we're loosing a lazyMaxMin into a maxMin.

I dunno if the lazy could be kept on AcceptsResults but I saw similar lazy lost when isAcceptedWithReasonBy was introduced (In this same class for instance).

[VincentLanglet]

Same, lazyOr into or.

[VincentLanglet]

Same lazyExtremeIdentity into extremeIdentity, like it's done for isAcceptedWithReasonBy

[ondrejmirtes]

This looks promising. Could you do a quick proof of concept where this might be useful?

In StrictComparisonOfDifferentTypesRule we could read the reasons and output them as a tip (similar to what places that call Type::acceptsWithReason() do). A great opportunity for that is MixedType::isSuperTypeOfWithReason() when there's a subtracted type. So instead of mixed~string === string is always false, the error message would stay the same, but additionally there'd be a tip about "Type string has been eliminated from mixed already."

[ondrejmirtes]

I understand it might be a bit challenging because we might have to propagate that all the way from initializerExprTypeResolver->resolveIdenticalType.

[ondrejmirtes]

Maybe better to leave it for later, so this can be merged. So nevermind for now, I'll review this PR.

[VincentLanglet]

Maybe better to leave it for later, so this can be merged. So nevermind for now, I'll review this PR.

Yes I had in mind to work on it step by step ^^'

[ondrejmirtes]

Hey, I was thinking about this a bit more and it'd help me if:

1. We didn't reuse AcceptsResult for the isSuperTypeOfWithReason return type.
2. This PR did not do any changes to AcceptsResult.
3. Instead, it introduced new class called IsSuperTypeOfResult by copying and modifying AcceptsResult to suit the method's needs.

After that I'm very likely to merge this.

[VincentLanglet]

Since I created isSubtypeOfWithReason too, does it mean we need a IsSubtypeOfResult too @ondrejmirtes ?

This may complicate things since i need to trasnform often subtypeOfResult into superTypeOfResult.

[ondrejmirtes]

@VincentLanglet It's fine to use IsSuperTypeOfResult for isSubtypeOf too.

[VincentLanglet]

1. We didn't reuse AcceptsResult for the isSuperTypeOfWithReason return type.
2. This PR did not do any changes to AcceptsResult.
3. Instead, it introduced new class called IsSuperTypeOfResult by copying and modifying AcceptsResult to suit the method's needs.

I'll end with something very similar for AcceptsResult and IsSuperTypeOfResult.
They will have the same and, or, ... methods.

I was wondering what's the idea between duplicating such code ; wouldn't it better to introduce something like a Result class which works for everything ?

It would make sens because there is code like

public function acceptsWithReason(Type $type, bool $strictTypes): AcceptsResult
	{
		if ($type instanceof CompoundType && !$type instanceof self) {
			return $type->isAcceptedWithReasonBy($this, $strictTypes);
		}

		return $this->isSuperTypeOfInternal($type, true);
	}
	
public function isSuperTypeOfWithReason(Type $type): IsSuperTypeOfResult
	{
		if ($type instanceof CompoundType && !$type instanceof self) {
			return $type->isSubTypeOfWithReason($this);
		}

		return $this->isSuperTypeOfInternal($type, false);
	}

So both method rely on isSuperTypeOfInternal and could use the same value object as return type.

Another "weird" situation is the fact that isParametersAcceptorSuperTypeOf currently returns an AcceptsResult when the method talk about SuperTypeOf...

phpstan-src/src/Type/CallableTypeHelper.php

Lines 15 to 19 in c77064a

	public static function isParametersAcceptorSuperTypeOf(
	CallableParametersAcceptor $ours,
	CallableParametersAcceptor $theirs,
	bool $treatMixedAsAny,
	): AcceptsResult

So I'm not sure how to evolve this PR with the use of a IsSuperTypeOf without using a lot of method like
IsSuperTypeOfResult::toAcceptsResult and AcceptsResult::ToIsSuperTypeOfResult.

[ondrejmirtes]

I was wondering what's the idea between duplicating such code ; wouldn't it better to introduce something like a Result class which works for everything ?

This is accidental duplication. The fact these are the same right now doesn't mean they're going to be the same in the future. I tend to develop a hunch for these things.

[ondrejmirtes]

Another "weird" situation is the fact that isParametersAcceptorSuperTypeOf currently returns an AcceptsResult when the method talk about SuperTypeOf...

This method should return IsSuperTypeOfResult in your PR, because it's used in isSuperTypeOfInternal methods.

[ondrejmirtes]

Hey, I need this really soon so I can announce an RC period for 2.0. I'm changing this locally right now.

[VincentLanglet]

Hey, I need this really soon so I can announce an RC period for 2.0. I'm changing this locally right now.

I started the changes, do you want me to stop and letting u doing all the changes then ? (Or I push the current changes ?)

[ondrejmirtes]

Thank you.

[VincentLanglet]

Thanks you too !