-
-
Notifications
You must be signed in to change notification settings - Fork 193
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
Change Closure to callable #321
Conversation
Psalm failing because of vimeo/psalm#8435 @greg0ire |
We prefer centralized ignore rules. Please add the link above when adding your ignore rule. |
Done |
Sorry, I meant centralized in the config file directly: Lines 16 to 40 in d93dbc5
If you use a baseline file, chances are the links you add are going to go away when using a command to re-generate the baseline. |
Fixed but IMHO psalm-suppress are the best because as soon as the version is released the psalm suppress is reported as useless, so you dont forget. |
That's great, I didn't know about this! I wonder why it does not happen when using a config file. |
Can you please add an entry to the upgrade file describing how to write an implementation of |
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.
A few nitpicks
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.
Is the issue we're fixing here still relevant in PHP 8.1 and first-class callable syntax? I'd rather drop support for callable
s other than Closure
s everywhere tbh.
I don't understand. Every closure are callable. So you're not dropping support for Closure.
|
I didn't even know about first-class callable syntax, but now I think @derrabus point is: should we encourage usage of ugly stuff like Line 36 in cec2511
@derrabus wasn't suggesting your PR did that. I think you missed the word "other" in his answer. |
I don't really see the point about restricting the param by ideology if the method can support it. It's acting like |
Also that doesn't solve the issue for Class with |
In that case, maybe it's better to merge this and let PHP itself deprecate |
Even if it's deprecated, callable will still be needed for invokable classes, no ? |
I suppose so. |
The Since with the new first-class callable syntax, creating Note that we're not simply building a brand-new API here: The PR proposes to change existing and established interfaces. A downstream implementation that wants to support v1 and v2 at the same time is either forces to drop parameter types on closure parameters completely or drop support for PHP 7 and use an ugly union type. If we were to pursue that path, it should be worth it, and I believe it's not.
a_function_that_expects_a_closure($myInvokableObject(...));
a_function_that_expects_a_closure((new MyInvokableClass)(...)); I understand that we would improve the situation for invokable objects a little by widening to I appreciate the effort you've put in this PR and I'm honestly sorry that I've jumped onto this train that late. But I'm genuinely not convinced that this change is still a good idea. |
Examples for fun times with callables: |
I still think callable should still be deprecated in php before refusing support for them. The issue were opened for 2 years, I recommend to close the issue if the change won't never be accepted. |
All right, since you're just repeating arguments you've already made, let's agree to disagree. This debate does not lead anywhere.
It might have been valid two years ago, but that does not mean we shouldn't reevaluate it after such a long time.
Yes, we should do that. WDYT @greg0ire? |
Let's close this, I think @derrabus is making good point, and you're right, we should close the issue as well. |
Close #231