std::any is pretty cool. You can use it, for example, to build a map where the key is just the type of the value.
So, you could query it like this:
let maybe_position = store.find::<Position>(id);
The id is the ID of an entity which may or may not have a Position associated with it.
This is similar to just using structs/OOP, so where you’d have a Vec<Entity> and then you’d call entity.position, but the big difference lies in flexibility. An Entity type would need to have all fields defined, which may ever exist on an entity.
With this type-as-key map approach, you can just tack on new attributes to entities and dynamically react to them.
All of this is basically how the storage works in the Entity-Component-System architecture (ECS), which is popular in gamedev, for example. But both the storage method and the ECS architecture are good tools to be aware of in normal software design, too.
Yeah, I thought of runtime duck typing when I saw it, which is essentially what an ECS is.
It would be pretty cool to go the next step and be able to find and call methods or discover trait implementations on the type that may not be in the signature. So something like how Go can conditionally type asset an interface to a different interface. I don’t know if that’s possible in a zero cost way (probably not), but it would be interesting.
TIL about
std::any.Congrats on another release! I’ll try it out this weekend. :)
std::anyis pretty cool. You can use it, for example, to build a map where the key is just the type of the value.So, you could query it like this:
let maybe_position = store.find::<Position>(id);The
idis the ID of anentitywhich may or may not have aPositionassociated with it.This is similar to just using structs/OOP, so where you’d have a
Vec<Entity>and then you’d callentity.position, but the big difference lies in flexibility. AnEntitytype would need to have all fields defined, which may ever exist on an entity.With this type-as-key map approach, you can just tack on new attributes to entities and dynamically react to them.
All of this is basically how the storage works in the Entity-Component-System architecture (ECS), which is popular in gamedev, for example. But both the storage method and the ECS architecture are good tools to be aware of in normal software design, too.
Yeah, I thought of runtime duck typing when I saw it, which is essentially what an ECS is.
It would be pretty cool to go the next step and be able to find and call methods or discover trait implementations on the type that may not be in the signature. So something like how Go can conditionally type asset an interface to a different interface. I don’t know if that’s possible in a zero cost way (probably not), but it would be interesting.