Repository navigation
Parameter and return type hinting #3
Description
Is your enhancement related to a problem? Please describe.
Should we include parameter and return type hints to accompany the strict types declaration? I would think if you use this package and extend the interface or abstract classes to register a post and add your own type hints in your project, that it would not be possible due to not following the interface contract. I personally use return and parameter hints more often than the strict types declaration so I'm curious why that is the pattern for this project.
Designs
No response
Describe alternatives you've considered
No response
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
darylldoyle commentedon Feb 3, 2025
@claytoncollie I don't disagree with adding param/return types, I actually think it's a great enhancement for the framework. There are two main reasons this version didn't ship with it:
Firstly, the scaffold doesn't use param/return types, and I didn't want to stray too far from how the scaffold is currently doing things.
Secondly, we don't currently have true generics in PHP (see here and here). Additionally, WordPress passes a lot of complex objects/arrays around that aren't wrapped in classes. This means we'd need to typehint using
Array, which I personally hate as it gives you little-to-no information on the actual content. For example. check out the options array when registering a taxonomy here.The return types set within the framework are understood by PHPStan, which I'd personally recommend everyone uses, and should catch any incompatibilities early. Also, any decent IDE should be able to read these and typehint correctly based on them.
As for the
strict_typesdeclaration, the main reason this is in place is to stop implicit type coercion. It's a feature of PHP I feel introduces more bugs than it solves, and being strict with types, in my opinion, will only ever lead to more robust software.