5 ms·

It is a perfectly reasonable way to test for interfaces. A single struct may satisfy a hundred interfaces which it doesn't even know about, this is actually one

• bsaul 12y ago
  I looked at this slide for a while and couldn't understand it. Could you explain the detail a bit ? It seems like relying on dynamic type casting over a nil variable, is that correct ? But then what would the following "if" look like ?
  • webtopaz 12y ago
    This is how you can make sure that a struct implements an interface. The line 'var _ scan.Writer = (*ColumnWriter)(nil)' assigns a nil pointer of the struct to a scan.Writer interface reference which would fail if ColumnWriter doesn't implement the interface. And the casting always works.
    • bsaul 12y ago
      So it's a static typing check ? the code won't even compile if the ColumnWriter struct doesn't implement the interface ?
      • webtopaz 12y ago
        Yes. It won't compile. This check is not really needed as the code would fail when a function which accepts scan.Writer would fail (compilation) if ColumnWriter is sent and if it doesn't satisfy the interface. However, this is easier to debug.
        • NateDad 12y ago
          Yeah, this type of check is nice if you intend to implement an interface, but don't actually use the type as that interface in your package. This will give a compile time error if your type doesn't satisfy the interface. You could write a test for it too, but this is a little simpler and harder to miss.
• pjmlp 12y ago
  No, it is a workaround pattern due to lack of language support.
  • howeman 12y ago
    You understand that the satisfaction is verified at compile time, right?
    • pjmlp 12y ago
      Sure I do. Other languages provide constructs to check for interface compliance, Go requires writing dummy code.
      • burntsushi 12y ago
        Go does not require it. Interface compliance is statically checked. This is a debugging trick because Go interfaces use structural subtyping instead of explicitly declaring which types implement an interface. This is a calculated design decision with several trade offs. There is nothing "sad" about it.
        • pjmlp 12y ago
          How do you list all interfaces a give type supports just by looking at it? Both by design, as well as, by accident (usually it different method semantics). You don't need to teach me Go, I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere.
          • burntsushi 12y ago
            > How do you list all interfaces a give type supports just by looking at it? By design, you can't. > You don't need to teach me Go Then don't state patently false claims. "Other languages provide constructs to check for interface compliance, Go requires writing dummy code." This is false because interface compliance is checked statically. This is orthogonal to whether you can list all interfaces satisfied by a given type. > I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere. That's not a feature unique to gonuts. If you disagree with a project's fundamental design and stated goals, then I'm not sure what else you might expect. For example, I'm not particularly interested in the JVM/Java world due to a myriad of design decisions that they've made. But I don't go around trolling the Internet with near content-free comments and inaccurate statements about their ecosystem.