-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[WIP] Use callable typehints #14330
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
[WIP] Use callable typehints #14330
Conversation
We should support all callable types (which is already the case in most places in Symfony). Restricting the callables being allowed would be both a BC break and a WTF for users |
$this->controller = $controller; | ||
} | ||
|
||
private function varToString($var) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this unused method should actually be removed in older branches
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah no sorry, it was used in the exception message
Also removes tests checking the exceptions thrown from the removed is_callable checks.
dd38335
to
2425766
Compare
|
*/ | ||
public function setNormalizationClosures(array $closures) | ||
public function setNormalizationCallbacks(array $callbacks) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renaming the method is a BC break
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stof this is for 3.0 and all these changes in this pr are bc breaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but in this case here (which is just about renaming without changed typehint) it is probably better to deprecate the method in 2.8 first and provide the new method. so there is an upgrade path. and then remove the old one in 3.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tobion the typehint changes are BC breaks only for people extending the classes, because of the E_STRICT (and for most places, they probably don't need to extend it). The method renaming is the only BC break affecting the usage of the class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make it perfectly clear, we don't want to break BC without providing an upgrade path. In this case, we should introduce the new method in 2.8, deprecate the old one in 2.8, and remove the deprecated on in 3.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I can open a separate PR with the naming changes and BC layer for 2.8.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All Config component changes now in #14364.
2425766
to
2b47634
Compare
2b47634
to
3f7e512
Compare
This involves a lot of signature changes and so many BC breaks for which we cannot really warn the user beforehand, not sure this is worth it. |
👎 from me: this should be changed on a case by case basis, when someone has an actual use case imo. Doing a global change is more a theoretical standpoint than a practical one. |
See #16125 for the callable type hint |
…nicolas-grekas) This PR was merged into the 3.0-dev branch. Discussion ---------- Replace is_callable checks with type hints | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #14330 | License | MIT | Doc PR | - Also removes tests checking the exceptions thrown from the removed is_callable checks. Commits ------- 7685cdd Add more callable type hints 4e0c6e1 Replace is_callable checks with type hints
Initially discussed in #14293, now includes those changes as well.
The
callable
typehint is used where applicable. Two types of changes are included:\Closure
typehintsis_callable()
checksThe PHP bug in the handling of callables of the
'Foo::bar'
type (https://bugs.php.net/bug.php?id=68475) causes some issues. To support every possible callable,call_user_func($func, ...)
needs to be used instead of using$func(...)
directly. Besides the more verbose syntax,call_user_func
is also slower. There are a few options on how to deal with this:call_user_func
.\Closure
.Even option 2 doesn't sound entirely unworkable to me, static callback strings are very unwieldy -- especially with namespaces. That the error is thrown at call time is less than ideal of course.
In these cases using
call_user_func
doesn't look like a too bad option either. But in other places noticeable performance improvements could be possible if existing code could be converted to use direct calls. So the decision may have implications beyond just this PR.In addition to handling the static strings, I still want to make sure that none of the
\Closure
typehints that were replaced were intentionally strict. The one typehint inOptionsResolver
mentioned by @stof in #14293 was already skipped.'Foo::bar'
type.\Closure
tocallable
changes are valid.