Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review parameter type declarations #873

Open
jrfnl opened this issue Jun 3, 2024 · 1 comment
Open

Review parameter type declarations #873

jrfnl opened this issue Jun 3, 2024 · 1 comment

Comments

@jrfnl
Copy link
Member

jrfnl commented Jun 3, 2024

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.

@jrfnl jrfnl modified the milestones: 2.2.0, 3.0.0 Jun 3, 2024
@jrfnl
Copy link
Member Author

jrfnl commented Jun 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant