Given a typedef of: “type ID int”
Is it possible to convert a map[ID]int to a map[int]int?
I’ve tried:
map[int]int(m)
as well as
m.(map[int]int)
and neither seems to work:
http://play.golang.org/p/oPzkUcgyaR
Any advice?
Edit more details, since a couple people asked.
What I’m trying to do is score a league.
There are a bunch of “Teams”, and each has a number of stats. For each stat, you get 10 points for being highest scoring, 9 for 2nd etc.
I modeled this as:
// Each team's statistics:
type StatLine map[StatID]float64
// The whole league:
map[TeamID]StatLine
// And I want to score that whole league with:
func score(s map[TeamID]StatLine) map[TeamID]int
// Only, is't also handy to score individual players:
func score(s map[PlayerID]StatLine) map[PlayerID]int
And it would be great not to write score() twice (since it’s the same logic) or copy the whole map over.
It happens that PlayerID and TeamID are ints, hence I was curious if I could just write score(s map[int]int) and do type conversion. However, SteveMcQwark makes it clear why this might be a bad idea.
I think generics would solve this, but I know they’re not immediately forthcoming. Any other ideas?
Thanks!
If you really want to do generics in Go, you need an interface. This interface will be implemented by two types, one for teams and one for players. The score function will take an object of this interface type as an argument and implement the common scoring logic without knowledge of whether it is working with teams or players. That’s the overview. Here are some details:
The method set of the interface will be exactly the functions that the score function will need. Lets start with two methods it would seem to need,
and a generic scoreable ID type,
The types that can implement this interface are not TeamID and PlayerID, but types that hold maps of them. Further, each of these types will need both maps, the StatLine and score maps. A struct works for this:
Implementing scoreable then,
Wait, you might say. That type conversion of scID to TeamID. Is that safe? Had we might as well just go with the low-enginering approach of not even having TeamID? Well, it’s safe as long as these methods are used sensibly. The struct teamScores associates a map of TeamIDs with another map of TeamIDs. Our soon-to-be-written generic function score takes this struct as an argument and thus is given the correct association. It cannot possibly mix up TeamIDs and PlayerIDs. That’s valuable and in a large enough program can justify this technique.
Do the same for PlayerID, define a similar struct and add the two methods.
Write the score function once. Start like this:
Oops, we need some way to iterate. An expedient solution would be to get a list of IDs. Let’s add that method:
and an implementation for teamScores:
Now where were we?
Notice the function takes the interface type scoreable, not pointer to interface like *scoreable. An interface can hold the pointer type *teamScores. No additional pointer to the interface is appropriate.
Finally, to call the generic function, we need an object of type teamScores. You probably already have the league stats, but might not have created the score map yet. You can do all this at once like this:
call:
And the team scores will be in ts.scores.