this is no longer used by the core, and as far as I can tell no plugin uses it either.
it was used in the past for chat broadcast channels, but not anymore.
during unset(), the destructors for other objects with cyclic references can get triggered, resulting in the functions being reentered before the count() call. This leads to a crash because the offset no longer exists.
Instead, we check if only the given PermissibleInternal is present, and clean everything up with a single unset instead of two.
This could also have been solved by adding extra isset() checks before checking the counts, but this way seemed more elegant.
This is similar to an issue with AsyncTask thread-local storage a few months ago, which was also caused by GC reentrancy.
closes#6119
I'm not quite sure this is the best way to enable such functionality, but it's already used for some other stuff, so I'm not too worried for now.
This allows the following commands to have their usage limited to self or others:
- /effect
- /enchant
- /gamemode
- /give
- /spawnpoint
- /teleport
- /title
I envision this being useful for creative mode servers, and test servers such as test.pmmp.io.
I've stuck to only doing this in the places where I'm sure we should never get false back. Other places I'm less sure of (and I found more bugs along the way).
this is not as good as phpstan/phpstan-src#769 (e.g. array_key_first()/array_key_last() aren't covered by this, nor is array_rand()) but it does eliminate the most infuriating cases where this usually crops up.
this interface is just about the most pointless code in all of PM or Bukkit. In over 4 million lines of code on Poggit, a Google search and a GitHub search, I didn't find a single usage of it that wasn't just bukkit internals code copy pasta, a spoon, a port of PM/Bukkit/whatever into a different language, or someone's generated javadoc.
this makes PermissionAttachment more and more like Permission, except that it doesn't have a name.
Right now, the only value of this API change is that it allows breaking references to dead Permissibles, but in the future it should be possible to reuse a single PermissionAttachment on multiple Permissibles.
there is no longer such a thing as a permission granted to 'everyone', since we're no longer limited to true/false/op/notop, and regular players are now assigned the pocketmine.group.user permission.
It's possible we might want to add more restricted groups than 'user' in the future, in which case it would be behaviour-BC-breaking to change the default assigned permissions when creating a new PermissibleBase. Therefore, it's better to not assign any permissions at all and let the caller decide.
In addition, this solves the problem of implied permission subscriptions and leak on PermissibleBase construction - if base permissions are provided, it should be expected that the permissible will subscribe to those permissions.
