these were not in the usage search because PhpStorm decided to refer to ChunkLoader->getLevel() for any Player references, which caused them to only show when that was searched.
There's also an undetected LSP violation with ChunkLoader because it requires returning Level and Position->getLevel() returns Level|null. I don't know why PHPStan doesn't complain about that.
this allows assuming that a position has a valid world in places where it's never expected to not be valid. Since this is the vast majority of usages, it eliminates a lot of possible null-pointer warnings given by static analysers.
TODO: Consider whether we can make Position->getLevel/World use this behaviour out of the box in the next major version.
This reverts commit 10317527e4012fb1dbb1661f2f7fc33b05a7a6d1.
this breaks user code which exceeds stack limits in legitimate
circumstances. For example, it should be OK to add 6000x diamond to a
player's inventory without being forced to manually split the count up
for addItem().
this isn't cached anymore, and would be a performance drag.
It would be nice to have some kind of fast path for this, but comparing NBT binary isn't it.
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.
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.
