c4t has a lot of situations where we have map[string]Foo but really mean map[id.ID]Foo, and have to do a lot of stringifying and destringifying of IDs to get them to fit in. This is because Go doesn't support slices in keys.
It may be significantly easier to instead represent IDs as something like
type ID struct {
id string
}
// or maybe:
type ID string
This would then, if I've read the go specification right, make it possible to use IDs directly as keys.
This will make certain operations (such as globbing, prefix/suffix tests, and comparison) slower, as we'll need to split the IDs into tags. It might be worth benchmarking these and seeing if we can get away with faster stringified implementations. One thing might be to store globs as
type Glob struct {
prefix, suffix string
}
(this could be how we store all IDs, or just the ones we expect to be globs).
c4t has a lot of situations where we have
map[string]Foobut really meanmap[id.ID]Foo, and have to do a lot of stringifying and destringifying of IDs to get them to fit in. This is because Go doesn't support slices in keys.It may be significantly easier to instead represent IDs as something like
This would then, if I've read the go specification right, make it possible to use IDs directly as keys.
This will make certain operations (such as globbing, prefix/suffix tests, and comparison) slower, as we'll need to split the IDs into tags. It might be worth benchmarking these and seeing if we can get away with faster stringified implementations. One thing might be to store globs as
(this could be how we store all IDs, or just the ones we expect to be globs).