-
Notifications
You must be signed in to change notification settings - Fork 10
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
Update Example in documentation? #36
Comments
The documentation could indeed be better, but I also highly question the necessity of this tool since we already have PHPStan. So unless someone still sees value in this, I'm going to let this tool die a silent death. Feel free to PR a better example, I'd still be happy to review it and merge it. Thank you for contributing. |
@rskuipers If PHPStan is already taking care about warning developpers to use assertions instead of assumptions, then you could deprecate this tool and redirect to PHPStan. But if not, then your tool is still valuable and shouldn't be left for dead 😄 And AFAIK, there's nothing like your tool included in PHPStan. |
@niconoe- I guess PHPStan doesn't exactly do this but it does follow the path and makes sure you don't do anything stupid with incorrect types, so it's a slightly different approach. I just checked the packagist statistics for fun but I never realized this tool is still in use today, pretty interesting. Did I disregard this tool's value too quickly? |
I wouldn't say "too quickly" as it seems you started to work on this long time ago... A colleague of mine found your repository as we are looking for QA tools in PHP and it felt like this "Assumption vs assertion" stuff was a new approach, even if we are already using PHPStan, Psalm, Qodana and other tools. Maybe the way you are orienting this analysis offers new QA criteria that could be something to care a little bit more in PHP ecosystem. Now, it's up to you if you prefer maintaining this approach, stop it, or propose it to another static analysis tool 😉 |
The example in documentation is a bit confusing as it's out of context. It wouldn't make immediate sense to those using mostly strict type hinting.
It needs to have the user class coming from something that could return another class type to make it absolutely clear.
A simpler way to describe it is instead of using assumption / assertion is to check for that it actually needs to be, that makes it clearly what's happening and if for example type hinting elsewhere already provides that guarantee.
The text was updated successfully, but these errors were encountered: