Related:

• 2.x Fix PHPStan issues on level 0 #2659

Issue

PHPStan reports "Unsafe usage of new static()" for some objects on level 0. What this means and how to solve this can be read in https://phpstan.org/blog/solving-phpstan-error-unsafe-usage-of-new-static.

Solution

Make the object constructors final. Not being able to overwrite a constructor seems like a good idea to me. As noted in the linked post:

So the PHPStan rule protects you from accidentally breaking your code when extending the class and defining a different constructor.

By making the constructors final, I already ran into an issue in PagesMenu, where I used a custom constructor. Removing the constructor and just updating the values on the object (or through a custom method) works fine.

This change was already discussed in #2203 (comment). In that discussion, there’s an example that wouldn’t work anymore with the change.

2. Making the constructor final precludes any user in the future doing anything involving a custom constructor. For example, I might want to do this:

class MyPost extends Post {
  protected function __construct($stuff, $things) {
    // do something special with $stuff and $things
  }

  public static function build( WP_Post $wp_post ) {
    [ $stuff, $things ] = SomeApi::special_sauce();
    return new static($stuff, $things);
  }  
}

Am I wrong to assume that this could be rewritten with a custom method do_something() that doesn’t change the constructor?

class MyPost extends Post {
  protected function do_something($stuff, $things) {
    // do something special with $stuff and $things
  }

  public static function build( WP_Post $wp_post ) {
    [ $stuff, $things ] = SomeApi::special_sauce();
    $object = new static($wp_post);

	$object->do_something($stuff, $things);
  }  
}

Impact

With final constructors, it will be easier to update constructors in the future, because we will not break backwards compatibility automatically. Otherwise, we’d have to assume that any constructor could have been overwritten.

Usage Changes

We won’t be able to overwrite the constructors in classes that extend the Timber core object. But it will still be possible to update the objects with other custom methods as shown above.

Considerations

In case we need some other functionality to make it easier to solve a certain use case, I’m sure we can come up with a proper API for that that doesn’t involve custom constructors.

Testing

Nothing in particular.