This isn't a bad solution. It's probably what I would do.<p>However, it's still worth addressing a bit of an issue I see in a lot of developer's heads, which is that they get so stuck on using one solution, even if it doesn't work in their language, that they forget about other ones. Prior to generics, the solution to this wouldn't have been to throw your hands up in the air and cry that there was no way to get the id generation code in one place. The solution would have been:<p><pre><code> func serializeXID(xID xid.ID, prefix string) string {
return fmt.Sprintf("%s_%s", prefix, xID.String())
}
type MySpecificID struct {
id xid.ID
// whatever else we need
}
func (msID MySpecificID) String() { return serializeXID("mytype", msID.id) }
</code></pre>
It is perfectly valid, in any language, to simply use functions to refactor commonly-used bits of functionality into functions. Go still has plenty of other places where this will be necessary for other reasons. (Go is far from a "functional language", but, at the same time, it kinda borrows that "simple functions are really really important" idea, and even post-generics, it doesn't have a bajillion things that boil down to functions wrapped in some language concept. It mostly just has functions. As the FP languages show, this is still pretty useful.)<p>As boilerplate goes, if you look at it, it isn't even <i>that</i> much more. Interfaces can still be used to ensure that the correct methods are guaranteed to be implemented. (In practice, such a basic interface can't be missed, and even if it is for some period of time, well, first, you learned something about your program you may not have expected, and second, the compiler will tell you exactly what the problem is.)<p>In completely other news, 'fmt.Sprintf("%s_%s", x, y)' is a dangerous pattern that I've been bitten by other developers deploying before. Underscores are too common in identifiers. In this particular case one of the identifiers is a nasty string that probably can't be mistaken but it still reflexively makes me nervous to see it, and there will still be some tricky considerations around splitting on the <i>proper</i> underscore if a resource type ends up with an underscore in it. You really ought to either use a character that can't be used in a resourceID... and <i>check</i> that... or escape the prefix so it's unambiguous. You can any of the many existing mechanisms for doing that that may work, or it can be as simple as replacing backslash with two backslashes and then underscore with backslash underscore. Then it will be possible to unambiguously split the resulting id.