Back in Bukkit as some recall it was a thing to have to worry about referencing the Player object and managing that your self in some way. The issue as I recall to the Player referencing the Chunk he was in thus referencing the World he was in and preventing all that stuff from being garbage collected if not managed properly or ignored. The same could be said about referencing World, Chunk, Block, and any other Entity.
Is this scenario going to exist with sponge as well or can we perhaps see some sort of constant wrapper that one may keep eternal reference of with the actual reference changing within when needed.
Such as the Player that we would reference contains only the offline info it self while the online reference gets set and removed as the player goes on and offline with the isOnline() method there to check if any of methods for online players only will throw an exception or not.
Maybe look at this topic: [Dev] Is there a need for an OfflinePlayer
You can use the UUID for players, worlds and entities, and maybe a vector for blocks/chunks if you want use them as Map keys.
Even when players change their name, the UUID is constant.
There is an issue with block movement (pistons, physics) if you use a vector for blocks.
I just feel like that sort of micro management of references can easily be handled and should be handled by the implementation. It just always seemed odd and not an obvious thing you need to do, and for something that could cause a good chunk of memory to not free up of all things.
I think this thread should be merged with the one linked above.
I am not talking about Offline and Online player, I am talking about references as a whole that you had to micro manage and de-reference them when needed.
I just used the Player reference as an example because it was the most talked about one at Bukkit.
Thinking about it the thread title I made last night doesn’t fit well, I’m going to change that
The whole OfflinePlayer debate is basically about this, and I think whatever will be decided there will also apply in other cases.
I feel like the API shouldn’t expose anything that developers shouldn’t store a strong reference to.
Oh I see, In that case ya merging makes sense. I was unaware that this topic was what the discussion in that thread was.
Yes I agree with you on that. If I reference something I don’t want to have to worry about de-referencing it.
To be honest, if you still want to reference a Player, you could use a WeakReference and make checks whether the weak reference is still valid, if not, attempt to refresh it. If the player reference is unrefreshable (Bukkit.getPlayer(UUID) returns null), then that means your reference needs to die, and or, removed from mappings.
Personally, I prefer to use UUID’s for keys since those are nigh impossible to leak external references, and have those UUID’s linked to a wrapper object that is keyd to the UUID of the Player.
What you just explained should be what the exposed Player object should be in of it self. Something that handles that internally without plugins needing to worry about it at all. such that Bukkit.getPlayer(UUID) returns the exact same reference always while the internal references are what are altered when the player logs in and off.
Same to be said for Block, World, and other references of similar nature.