Closed dt-rush closed 1 year ago
Say if we did, in sameriver:
type ComponentType int
const (
Vec2D ComponentType = iota
Bool
Int
Float64
Time
...
)
this would be exported to the user as sameriver.Vec2D
, kind of cumbersome. Consider Spawn()
, your map keys would be crazy.
So maybe Spawn() we allow strings, but then also consider, what about getting component data?
e.GetVec2D(sameriver.Position)
doesn't really look good either. You'd almost like to - at compile time - map the strings in the code to the int values they should be.
And I almost wonder if, given that a map key lookup can be known to be constant string in a given expression at compile-time, does the go compiler just take the constant string's hash at compile time and turn the map lookups during evaluation of that expression into direct bucket access? It seems unlikely...
and anyways, again, is this even a problem? hashing a string is pretty fast. I wonder if it becomes noticeable for longer-length component names like "SpaceshipDoorPanelAccessCodeMap"
As of commit 4c83cc354a490ae69afd6a3cf5845df775445365 this is dealt with. We now use ints.
should we use const ints instead of strings for component names?