You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While looking at something different, we noticed a number of places where parameters did not have (non-scalar) type declarations, while they could have.
It would probably be a good idea to do a review of the complete codebase to add object-based/array type declarations wherever possible.
This would not be a breaking change as overloading methods not having a type declaration, means those are declared as mixed and mixed is contravariant with any type, so this would not lead to signature mismatch errors.
The text was updated successfully, but these errors were encountered:
Currently having a prelim look at this and I am now doubting we can actually do this in a minor as certain code would either:
start throwing a TypeError/Exception where previously it would silently accept the incorrect type and somehow handle it; or
the code would previously throw a different type of exception ( WpOrg\Requests\Exception\InvalidArgument most typically), so the change of which exception is being thrown could be seen as a breaking change as WpOrg\Requests\Exception\InvalidArgument does not extend TypeError.
With that in mind, I'm moving this to the 3.0 milestone.
While looking at something different, we noticed a number of places where parameters did not have (non-scalar) type declarations, while they could have.
It would probably be a good idea to do a review of the complete codebase to add object-based/array type declarations wherever possible.
This would not be a breaking change as overloading methods not having a type declaration, means those are declared as
mixed
andmixed
is contravariant with any type, so this would not lead to signature mismatch errors.The text was updated successfully, but these errors were encountered: