-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
Stricter input/output type declaration, matching original type signatures from 2.0.0-beta5
release
#23
Conversation
Signed-off-by: Carnage <t.carnage@gmail.com>
42646ad
to
b877686
Compare
Marked for Effectively, this is an improvement that mitigates the problems found in #20, and if call-site consumers of the code use In addition to that, I decided to not mark this as
|
I'll merge this manually after having applied some cleanup operations (CS/QA checks, mostly) |
Since the constructor of `Escaper` now asserts the input to be of type `string|null`, we no longer need to assert by hand on mis-behavior, and therefore can remove an exception scenario, as well as the associated test case.
Since we now use native parameter type declarations, we no longer need to have `@param string $param` declarations. Also, `is_string()` and `gettype()` are no longer in use (were used when throwing an exception based on invalid input). Note that `@return string` is preserved: we cannot introduce native return type declarations, as that would lead to downstream crashes in inheritance scenarios, when the consumer didn't declare `: string` return types themselves too.
2.0.0-beta5
release
Thanks @carnage! |
Signed-off-by: Carnage t.carnage@gmail.com
Description
The introduction of strict types in the file heading is propagated to calling code as the required types are missing from the method signatures. This PR adds the types and resolves the BC break.
While adding types to the methods could be considered a BC break in itself, I cannot conceive of any sensible use case that this change would impact.