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

In param tags variable name is optional #165

Closed
wants to merge 1 commit into from

Conversation

jaapio
Copy link
Contributor

@jaapio jaapio commented Nov 15, 2022

Accoring to the PRS-5 standard paramnames are optional. The parser does not force docblocks to be fully valid, so it's ok to have multiple param tags without variable name. However this should never happen in real world docblocks.

Fixes #164

Accoring to the PRS-5 standard paramnames are optional. The
parser does not force docblocks to be fully valid, so it's ok to
have multiple param tags without variable name. However this should
never happen in real world docblocks.

Fixes phpstan#164
@jaapio
Copy link
Contributor Author

jaapio commented Dec 10, 2022

@ondrejmirtes a friendly reminder for this pr, is there more work required to get this merged?

@ondrejmirtes
Copy link
Member

Hi, I disagree with this one, it doesn't make sense to add now imho.

@ondrejmirtes
Copy link
Member

I see @param as a parameterName => type map. To allow entries without a parameter name doesn't make sense to me. PHPStan enforces this for many years, there isn't going to be much code left that looks like this.

@jaapio
Copy link
Contributor Author

jaapio commented Dec 10, 2022

Thanks for your response, I will try to solve this in a different way. As phpDocumentor still requires the support for this. How much I would love to remove this.

It would help to remove this from psr-5. A discussion we are both part of. I will close this pr.

@jaapio jaapio closed this Dec 10, 2022
@ondrejmirtes
Copy link
Member

Is there any activity going around PSR-5? Seems dead and outdated to me at this point. I don't think we really need it :)

@jaapio
Copy link
Contributor Author

jaapio commented Dec 10, 2022

It's still alive. The main reason I think it makes sense is because we (phpDocumentor, phpstan and psalm) are all working in the same area. Where you are doing an awesome job, thank you very much for that.

I think when we bundle our strengths to make a good standard the whole community will benefit from that. Making documentation and static analyse go hand in hand together. One of the reasons I'm now trying to integrate this parser into our code. So we can support all types supported by phpstan. This will also give me the opportunity to help you improve this project.

Phpstorm has always followed phpDocumentor, and generics support was delayed because it was not part of psr-5. You can find this in their issue tracker. I'm sure that when we standardize things we will also have them on board to support all the awesomeness you are working on.

I don't want to drag you into a political discussion, that would be a waist of our time. But I'm convinced of the fact that standards help to improve the adoption of new technologies.

I wanted to have a chat with you about this topic at symfonycon. But I didn't have time to meet you somewhere.

Thanks a again for helping me in my daily work with phpstan. And I hope we can have a chat about the possibilities in type strict php at some point.

@ondrejmirtes
Copy link
Member

But our tools move faster than any standard could. If the standard is ever "published", it will be obsolete in a month.

Right now the tools ecosystem is doing totally fine without any standard, including PhpStorm which follows what Psalm and PHPStan do.

Thank you for understanding too :)

@jaapio jaapio deleted the feature/optional_param_name branch March 12, 2023 10:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[PSR-5] param tag with optional values
2 participants