fix: add explicit nullable types to constructor parameters to avoid deprecation notes on PHP 8.4#191
fix: add explicit nullable types to constructor parameters to avoid deprecation notes on PHP 8.4#191
Conversation
- Add explicit nullable type hints (?array, ?Configuration, etc.) to constructor parameters in Model and API classes - Update PHPDoc comments to reflect nullable parameter types - Resolves PHP 8.4+ deprecation warnings for implicitly nullable parameters Affected files: - lib/Model/Postcard.php - lib/Model/Thumbnail.php - lib/Model/UsVerification.php - lib/Model/IntlVerification.php - lib/Model/AddressEditable.php - lib/Model/PostcardEditable.php - lib/Api/PostcardsApi.php This follows conventional commit format with: - fix: type since it resolves deprecation warnings - Clear description of what was changed - Explanation of why (resolves deprecation warnings) - List of affected files for easy reference
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @alies-dev, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request addresses PHP 8.4+ deprecation warnings by introducing explicit nullable type declarations for constructor parameters in several Model and API classes. The primary goal is to ensure the codebase remains compatible with newer PHP versions and avoids runtime warnings, without impacting existing functionality or requiring breaking changes.
Highlights
- PHP 8.4 Deprecation Fix: Explicitly added nullable type hints to constructor parameters across various Model and API classes to resolve deprecation warnings introduced in PHP 8.4+.
- PHPDoc Updates: Updated corresponding PHPDoc comments to accurately reflect the newly introduced nullable types, ensuring documentation consistency.
- Backward Compatibility: The changes maintain full backward compatibility, ensuring the library continues to function as expected with older PHP versions while being future-proofed for PHP 8.4+.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request correctly addresses the PHP 8.4 deprecation of implicitly nullable types by adding explicit nullable type hints (?) to constructor parameters. The changes are consistent across all modified model and API classes, and the corresponding PHPDoc comments have been updated accordingly. This is a good improvement for future compatibility. I have one minor suggestion to improve documentation completeness.
|
Hey @hpelletier Sorry for pinging you dirrectly. This PR is 2 months old and a safe one (nullable types are introduced in PHP 7.1 (and 7.3 is the minimal supported version for this package), so I think we can merge it. If you have any doubdts - I would like to know them. Thank you! 🙏 |
1 participant
Summary
Fixes PHP 8.4+ deprecation warnings by adding explicit nullable type hints to constructor parameters across Model and API classes.
Problem
The codebase was generating deprecation warnings like:
This occurs because PHP 8.4+ requires explicit nullable type declarations (e.g.,
?array $data = null) instead of implicitly nullable parameters(array $data = null).Solution
(?array, ?Configuration, ?ClientInterface, ?HeaderSelector)to constructor parametersVerify