phpstan doesn't report these out of the box, for reasons I'm not clear on. It's also not clear if having null defaults has any effect on nullability behaviour, so they are best removed. In addition, these would be problematic on 7.4.
isPaired() returning true is not semantically equivalent to getPair() returning non-null. getPair() might return null if the pair is inaccessible, such as when it's in an unloaded chunk (it doesn't check this yet, but it should).
For the sake of opening inventory, we don't care if the chest believes if it is paired, we care if there is actually a pair to be accessed for inventory viewing.
In addition, it's possible to create this broken-data scenario artificially by close()ing a chest tile without unpairing it first, because a tile doesn't know the difference between being closed due to unload and being destroyed.
This will now throw an exception at the source instead of crashing when the entity is saved, which should put the blame on the correct plugin responsible for this.
This also includes magic method hacks to preserve backwards compatibility, since the fireTicks field is now protected.
This is better for performance because these then don't need to be reevaluated every time they are called.
When encountering an unqualified function or constant reference, PHP will first try to locate a symbol in the current namespace by that name, and then fall back to the global namespace.
This short-circuits the check, which has substantial performance effects in some cases - in particular, ord(), chr() and strlen() show ~1500x faster calls when they are fully qualified.
However, this doesn't mean that PM is getting a massive amount faster. In real world terms, this translates to about 10-15% performance improvement.
But before anyone gets excited, you should know that the CodeOptimizer in the PreProcessor repo has been applying fully-qualified symbol optimizations to Jenkins builds for years, which is one of the reasons why Jenkins builds have better performance than home-built or source installations.
We're choosing to do this for the sake of future SafePHP integration and also to be able to get rid of the buggy CodeOptimizer, so that phar and source are more consistent.
