okay, so I want to create the following structure:...

# getting-started

[Everett Corvid]

okay, so I want to create the following structure:
I want to create a superclass called Entity, and every Entity will have an instance of a data class called Position, which will have an x, y, and z property; z being floor, and x/y being position on a grid.
Now, I want to represent this grid as some type of collection where each Entity object is accessible by accessing the list by it's Position; perhaps by defining the hash for an object as its Position object instance

So, my four questions about the above:
1. Is there any kind of inherent issue with the structure of the above
2. What datatype would be best for accessing the Entity object from a collection based on the hash of its Position instance, and is there any collection type which can do so without needing to update the hash/reference pair every time an objects Position object changes
3. How do I make a collection of Nullable objects? Some of them make sense, for example arrays and lists are easy, but how would I make a HashMap nullable? Is it just HashMapKey, Value? - Essentially, I want to be able to easily remove the reference to an Entity in the collection and make it so there is no reference to an Entity object at the hash of the Position object, and so that it just returns null if you try to get whats at that Position hash
4. Finally, is there any way to pre-emptively define what hashes are valid? For example if I create a grid and define what spaces are valid spaces on that grid, can I use that to instantiate the hashmap or whatever collection works best so that only those specified hashes are valid? I.E. only the hash of Position objects with a z of 2 and this list of x/y combinations are valid keys for this hashmap, and all of those hashes are instantiated with a null at that hash, then later I insert the Entity references

[CLOVIS]

1. Depends on what you want to do with it.
2. That's going to be complicated. Ordered/sorted collections have to restructure themselves when the contents change, it can be costly. But more importantly, they need to be aware of the change. You could have a HashMap<Position, Set<Entity>> , but each time you wanted to change an entity's position, you would have to remove it from the previous position and add it back to the new position. If you forget to do it somewhere, you risk positions being desynchronized with entities. Also, you would need a stable way to compare entities (to find the one you want to delete), meaning all entities should have a hashCode/equals that doesn't change.
3. Yes, HashMap<Key, Value?> allows storing null for a given key. However, I'm not sure that's what you want here: do you want to store empty values? I think you just want to remove the key altogether when there are no entities at that position. Map.get already returns a nullable value in case they key was not found.
4. The standard library collections do not have this feature, but you could custom-made structures that do. For example, if you know your entire grid is relatively small (= not an issue to store it entirely in memory), you could use an Array<Array<Array<Set<Entity>>>> where each array is one of the dimensions. This would by far be the fastest, but the memory cost is huge.
What you're asking about is called space partitioning. I encourage you to read about the different data structures and their pro/cons. When you find one you like, don't hesitate to ask for help to implement it 🙂

[Klitos Kyriacou]

I was just thinking whether it would be a good idea to use the observable delegate for the Position of an Entity, so that whenever an entity's position changes, the delegate deletes and re-adds the entity to the position map. Also, you could make the Entity only instantiable by a method belonging to a class that holds your position map, so that you can only create an Entity instance that knows how to add itself to the position map.