We are using func_get_arg method to receive argument in a backward compatible way since we cannot modify function signature to add more params even with default params. Earlier I was hoping to use DI to create another child class with modified signature and load it depending upon where we are executing from, however since we had to revert DI, we add this workaround to unblock #27735.
- One dummy class used for tests had a 'final private' method, this
is not allowed in PHP 8 and so the method is now just 'private'.
- The AbstractServiceProvider class was using
ReflectionParameter::getClass. This is deprecated in PHP8 and thus
that usage has been replaced with an utility method that uses
the recommended replacement.
- Passing a string that represents a number but has spaces (e.g. ' 1 ')
now works as expected (the number is properly interpreted)
- Passing the boolean true now returns 1, not 0
- Passing an object throws an error, instead of returning 0
After the League's Container package has been reintroduced, all the
code that implements the dependency injection mechanism in woocommerce
can be brought back as well.
There's a number of places in the WooCommerce codebase where the
built-in function 'round' is executed passing a non-numeric value
(not a number and not a string that can be parsed as a number),
for example round(''). In PHP 7 this yields a value of 0, but in
PHP 8 this throws an error.
This commit adds a 'NumberUtil' class with a static 'round' method,
this method checks if the passed value is numeric and if so it just
executes the built-in function, otherwise it returns 0. And all the
calls to 'round' in the codebase are replaced with 'NumberUtil::round'.
Since reverting the PR at this point would be a mess I've gone ahead and removed the internals of the container. We should aim to keep the class since it's now part of our public API but it won't work as expected anymore. This is fine for now since we don't actually have anything in it!
1. Since our code style dictates that these be `final` methods, we shouldn't be concerned about overlap.
2. There is precedent for `init` methods as requirements before using class instances.
Roy Ho
vedanshujain
jonathansadowski
Claudio Sanches
Nestor Soriano
Rodrigo Primo
Christopher Allford