Re:Practical Go: Real-world advice for writing maintainable ...
by samstokes on Thursday February 21, 2019 @03:12PM
(#19220154)
How about describing the intended use of the collections? E.g.
var usersByUsername map[string]*User
var usersToEmail []*User
Re:Practical Go: Real-world advice for writing maintainable ...
by jpttsn on Thursday February 21, 2019 @03:09PM
(#19220126)
I’d call the former usersByID (if that’s what the string is)
Re:Practical Go: Real-world advice for writing maintainable ...
by vorg on Thursday February 21, 2019 @07:17PM
(#19221931)
You could use a struct with private fields, e.g.
type Users struct{
dict map[string]*User
list []*User
}
and attach methods to both access the data and coordinatedly update both forms, e.g. func (us *Users) byID(id string) *User { ... }
func (us *Users) sortedByID() []*User { ... }
func (us *Users) addUser(id string, nu *User) {
dict[id] = nu
list = append(list, nu)
...
}
Re:Practical Go: Real-world advice for writing maintainable ...
by jimsmart on Saturday February 23, 2019 @12:39AM
(#19231883)
Personally I'd use usersByID and users - I nearly always name my maps thingsByKey, and my default is that a plural thing on its own is nearly always a list, so adding a suffix of List doesn't add anything much here for me (Cheney's "Don’t name your variables for their types").
What's the best way to handle a situation where you use two different types for the same data? e.g.