Open jrfnl opened 5 months ago
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:
TypeError
/Exception
where previously it would silently accept the incorrect type and somehow handle it; or 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.