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

Add ResultInterface template #67

Closed
wants to merge 2 commits into from

Conversation

bram123
Copy link
Contributor

@bram123 bram123 commented Jan 5, 2023

Q A
Documentation no
Bugfix no
BC Break maybe
New Feature no
RFC yes
QA no

Add ResultInterface template for the data field, for strict typing in the Check classes.

Started with DiskFree and DiskUsage checks.

  • Changed the data value/structure so it's visible what kind of data is returned as well

If acceptable I will continue with the other checks.

Signed-off-by: Bram Leeda [email protected]

…in the Check classes.

Started with DiskFree and DiskUsage checks.
- Changed the `data` value/structure so it's visible what kind of data is returned as well

If acceptable I will continue with the other checks.

Signed-off-by: Bram Leeda <[email protected]>
@bram123
Copy link
Contributor Author

bram123 commented Jan 5, 2023

Had to add @template to all Result implementation classes (success/warning/skip/failure) and all interfaces.
For some reason psalm did not let me set the @return docblock to ResultInterface, I had to set it to Success|Warning|Failure

@bram123 bram123 marked this pull request as ready for review January 5, 2023 11:09
@Ocramius Ocramius added this to the 1.24.0 milestone Jan 30, 2023
@Ocramius Ocramius self-assigned this Jan 30, 2023
Comment on lines +35 to 37
* @psalm-type ResultData array{availability: array{value: float, valueType: string}}
*/
class DiskFree extends AbstractCheck implements CheckInterface
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think CheckInterface should specify the psalm template here: not each concrete implementation.

Declaring an @template TResult of Failure|Success|Warning on the interface should highlight the missing @template-implements in each implementation of CheckInterface, and then we can remove all manual @return declarations on each of the check() methods.

WDYT?

Copy link
Contributor Author

@bram123 bram123 Jan 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ocramius
That means that other code repositories with custom implementations of the interface, would also have failing psalm/phpstan checks after updating right?
It would be the better solution yes, and mean that all new checks would also set this up.
If the static-analysis issue is okay (don't know if it falls under a bc break, as the code api doesnt change) I will change this :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they would get a failure during analysis, but we don't really consider those BC breaks: the code works as it did before, and the types are just more precise.

Copy link
Contributor Author

@bram123 bram123 Feb 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ocramius
Did a small test, and the current psalm version (4.30) does not error when I add a template to CheckInterface. Updating locally to psalm 5.6 does trigger MissingTemplateParam errors, but I see that update is being worked on in #62

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would leave #62 alone for now :)

As for the patch: please rebase, instead of merging upstream.

@Ocramius Ocramius assigned bram123 and unassigned Ocramius Jan 30, 2023
@Ocramius Ocramius removed this from the 1.24.0 milestone Feb 1, 2023
@bram123 bram123 changed the base branch from 1.24.x to 1.25.x February 1, 2023 13:44
@Ocramius Ocramius added this to the 1.25.0 milestone Feb 1, 2023
@Xerkus Xerkus modified the milestones: 1.25.0, 1.26.0 Dec 12, 2023
@bram123 bram123 closed this Feb 9, 2024
@samsonasik samsonasik removed this from the 1.26.0 milestone Nov 10, 2024
@samsonasik
Copy link
Member

I removed from milestone since PR is closed by author.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants