Go interfaces are not my sort of interfaces
I've written about interfaces before, or at least what I mean by the term (and how it relates to inheritance). To summarize, 'interfaces' are a way of formally expressing 'is-a' relationships; when you say that a class or a type implements the String interface, you mean that it is a string.
One of the things that jogged my mind about the whole issue was Go, which has things that it calls 'interfaces' (okay, technically they're called interface types). After thinking about it, it's become clear to me that what Go calls interfaces are not what I'm calling interfaces here; instead, they are a way of doing vaguely checked duck typing.
The problem with Go interfaces (from the perspective of being my sort of interfaces) is that no one actively asserts that a class implements an interface. Instead, an interface to class relationship is passively discovered as valid by the compiler. Because this relationship is not actively asserted, it is subject to inadvertent duck typing naming collisions, where a class coincidentally has a method or three with acceptable names and signatures.
Requiring active assertion, instead of mere passive discovery, means that at least someone told you (the compiler, the programmer, etc) that type <X> was a compiled regular expression or a string or whatever, and any inaccuracies in this statement are clearly their fault or at least mean that someone is wrong and you can fix the error. (And no programming language can really save you from active lies.)
(Note that this is my confusion, not particularly Go's; Go has merely chosen a somewhat overloaded and imprecise term because it was a good one for their purposes. Various Go people have written quite clear things about what Go interfaces do and are there for.)
|
|