A little irritating (but understandable) limitation on Go interfaces
I was all set to write an entry about how you could use Go-style interfaces to create what I called
easy, type-safe conversions from a variety of types to something you
wanted. The sketch of the problem and the idea is that suppose you
want to create an API that accepts arguments in multiple forms (eg), for example something in uncompiled string
form or in a compiled efficient form. The usual way to implement this is
with a type switch in your functions ('if argument is a string, convert
it to ...') but this annoying and limited.
Interfaces to the rescue, in theory: define a 'Converter' interface
with a single 'ToMyThing()' method, make your API take Converter
arguments (and your functions then call
define a new
ToMyThing() method on strings, integers, and whatever
else you want to accept.
ToMyThing() method for your actual type does nothing and just
People who know Go are shaking their head sadly right about now. Here, let me tell you why:
prog.go:9: cannot define new methods on non-local type string
Well, oops. So much for that.
If you understand how Go's types and interfaces are implemented, this
makes sense. One of the parts of the type description for every concrete
Go type is a static, fixed array of methods (with various information
including their name and a function pointer); this is built as the type
is compiled. What this error message really means is 'the method array
string has already been built, you can't add entries to it now'.
It's not hard to see why allowing this would massively complicate Go's life. The big reason is that entries in the method array are sorted by name (for good reason). Adding a name to it after the type has been compiled means re-sorting the array, changing the index position of entries, and then finding and changing all references to now-invalid index positions in already compiled code. In practice you would want to defer the index position resolution until link time (as a form of link time relocation) and I'm not sure that's even possible in object formats like ELF. Certainly it would add a lot more complexity to the whole process.
(Actually it's even worse; you would have to defer building the method
table entirely until link time, since you might have to merge together
string method definitions from all over your code base.)
You would also open up the possibility of weird link-time errors.
For example, suppose that two separate bits of Go code both
independently decide to add (different)
Convert() methods to
string. This pretty much has to be an error, but it's something
you can only detect and report at link time. Worse, those bits of
Go code work independently; they only fail when you combine them
into a single program. This is not a recipe for good software
engineering and I'm
not at all surprised that Go left this out.