[wp-trac] [WordPress Trac] #62061: Prepare for PHP 8.4

[WordPress Trac]

#62061: Prepare for PHP 8.4
---------------------------------------------+-----------------------------
 Reporter:  jrf                              |       Owner:  (none)
     Type:  task (blessed)                   |      Status:  new
 Priority:  normal                           |   Milestone:  6.7
Component:  General                          |     Version:
 Severity:  normal                           |  Resolution:
 Keywords:  php-84 has-patch has-unit-tests  |     Focuses:  php-
                                             |  compatibility
---------------------------------------------+-----------------------------

Comment (by hellofromTonya):

 In [changeset:"59052" 59052]:
 {{{
 #!CommitTicketReference repository="" revision="59052"
 Tests: Fix implicitly nullable parameters in
 Tests_HtmlApi_WpHtmlProcessorComments.

 PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameters
 with a `null` default value, which are not explicitly declared as
 nullable.

 The `Tests_HtmlApi_WpHtmlProcessorComments` test class contains one
 problematic parameter in the `test_comment_processing()` method
 declaration.

 While this could be fixed by adding the nullability operator, the type
 declarations in the test method is removed instead, including other type
 declarations for this method and the second test method, which were not
 affected by the deprecation.

 The reason for this is quite straight-forward: using type declarations in
 tests is bad practice and inhibits defense-in-depth type testing.

 Using type declarations in tests prevents being able to test the "code
 under test" with unexpected input types as the values with unexpected
 (scalar) types will be juggled to the expected type between the data
 provider and the test method and the _real_ data value would therefore
 never reach the method under test.

 The knock-on effects of this are:
 * That the input handling of the "code under test" can not be safeguarded,
 whether this input handling is done via in-function type checking or via a
 type declaration in the "code under test".
 * That if such "unexpected data type" tests are added to the data
 provider, they will silently pass (due to the type being juggled before
 reaching the "code under test"), giving a false sense of security, while
 in actual fact, these data sets would not be testing anything at all and
 if, for instance, the type declaration in the "code under test" would be
 removed, these tests would still pass, while by rights they should start
 failing.

 Also note that this problem would only be exacerbated if the file would be
 put under `strict_types`.

 Ref: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types

 Follow-up to [58734].

 Props jrf.
 See #62061.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62061#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform