-
Notifications
You must be signed in to change notification settings - Fork 7.8k
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
Override static in return types with self in final classes #17725
Comments
I cannot see anything wrong with this transformation either.
|
It's sound, but is it necessary? If the child removes |
Letting the engine do it would be fine, although it is obviously observable. Might be worth sending a quick e-mail to the list. |
…self in final classes
I added union types support for this feature and wrote additional tests for it. But I don't understand how to add support for this with intersection types) So for now I just added the !intersection check :) Maybe someone else can do this? |
Yes, there may be some inconvenience with this. But here, in fact, we are talking only about the fact that the language has the ability to replace static with self. This should not be mandatory. For me personally, it would be convenient. I am used to not using the static keyword inside when writing final classes, because it is a little confusing. |
It seems to me that using static inside classes always implies that the class can have children. And when static occurs in the final class, it's a bit confusing. So I'd like to see the language provide the ability to replace static with self, because again, it's not a violation of covariance. |
Okay, i'll send |
You don't need to handle intersection types as they cannot contain |
…tests to folder Zend/tests/type_declarations/variance/override_static_with_self
Description
After implementing static types in return methods, I noticed one thing that was illogical, in my opinion.
We have the following code:
It seems to me that in final classes, redefining return types in methods from static to self will not be a violation of covariance, because the final class will never have children. But now it triggers an error
Fatal error: Declaration of Foo::method2(): Foo must be compatible with B::method2(): static
. What do you think about this?In addition, the same PHPStorm suggests replacing static types with self types in final classes (if this type is not specified in the prototype).
Below I attach a link to the pull request in which I implemented this logic.
#17724
The text was updated successfully, but these errors were encountered: