PHP 8.0 introduces the concept of union types, which allows us to explicitly type a function with multiple different types. php-cypher-dsl currently polyfills this feature through the ErrorTrait trait. However, there are a few problems with this polyfill approach:
- It is not understood by IDE's, which makes refactoring hard;
- It requires an additional function call;
- Type-checking is only done at the deepest call;
- It does not work for interfaces or abstract methods.
Therefore, I want to propose to drop support for PHP 7.4 and start using PHP 8.0 union types. Implementing this is relatively straightforward:
- Add union types where needed to return types;
- Add union types where needed to argument types;
- Add union types where needed to class parameter types;
- Remove any references to the
ErrorTrait trait.
The ErrorTrait trait also has a method for checking whether the type of each value in an array is allowed. This is currently not supported through PHP's type system. There are two options to fix this:
- Use PHPDoc to specify which types the array allows and use PHP's native
array type in signatures, or
- Keep supporting the type-checking of arrays.
I think the first option is best. Type checking of arrays is only used in a few places (five times throughout the entire library), and it adds complexity and overhead. Most usages can also be replaced by typed variadic parameters.
PHP 8.0 introduces the concept of union types, which allows us to explicitly type a function with multiple different types. php-cypher-dsl currently polyfills this feature through the
ErrorTraittrait. However, there are a few problems with this polyfill approach:Therefore, I want to propose to drop support for PHP 7.4 and start using PHP 8.0 union types. Implementing this is relatively straightforward:
ErrorTraittrait.The
ErrorTraittrait also has a method for checking whether the type of each value in an array is allowed. This is currently not supported through PHP's type system. There are two options to fix this:arraytype in signatures, orI think the first option is best. Type checking of arrays is only used in a few places (five times throughout the entire library), and it adds complexity and overhead. Most usages can also be replaced by typed variadic parameters.