3 ms·

This is not an issue in any kind of real code written by a human being. When would you ever pass a cowboy object into a screen painting function? You'd never

by NateDad 13y ago

This is not an issue in any kind of real code written by a human being. When would you ever pass a cowboy object into a screen painting function? You'd never do this: cb := cowboy.New() screen.Paint(cb) Anyone who wrote that code would have to be insane, and anyone reviewing the code would tell the person they were insane. Also, would you not test your code? Like, at least run it and make sure it doesn't do crazy stuff? Maybe write some unit tests? There can always be edge cases where functions don't work precisely as you expect, but that happens without interfaces, too. Pass an array into a sorting function and it turns out to sort by string length not alphabetically.... the programmer bears some small responsibility for actually understanding what the functions that he calls actually do.

fauigerzigerk 13y ago
I agree that it's generally not such a big problem. It may be useful to draw a cowboy on the screen, but it's more likely that confusion could arise with methods that do something related, not something entirely different. For instance, in JDBC there is a PooledConnection.close() method and a Connection.close() method. Both Connection and PooledConnection are interfaces. They are semantically related but it's not a polymorphic relationship. PooledConnection does not extend Connection. PooledConnection.close() must always close the actual physical connection to the database because PooledConnection is used by the connection pool itself. The Connection interface is used by the application and hence Connection.close() may close the connection or return it to a connection pool. JDBC drivers usually come with implementations of both interfaces where the Connection implementation wraps an instance of a PooledConnection implementation. Arguably, being able to formally declare which interface a particular close method belongs to is beneficial in cases like this.
- NateDad 13y ago
  I think this is really a problem that exists beyond interfaces. For example, even if you had these two concrete types, and both had close methods, how would you know when to call one close versus another and what they do? This kind of confusion is a perpetual problem... and I don't think Go interfaces make it any worse, really.
  - fauigerzigerk 13y ago
    I would know because the concrete types formally reference an interface, and the documentation of the interface would tell me more about the intended semantics. You're right that simply having this formal reference doesn't solve all problems that could possibly arise. But there's one form of confusion that is much less likely to arise. As is so often the case, more flexibility comes with more opportunity for screw-ups.

by NateDad 13y ago

fauigerzigerk 13y ago

I agree that it's generally not such a big problem. It may be useful to draw a cowboy on the screen, but it's more likely that confusion could arise with methods that do something related, not something entirely different. For instance, in JDBC there is a PooledConnection.close() method and a Connection.close() method. Both Connection and PooledConnection are interfaces. They are semantically related but it's not a polymorphic relationship. PooledConnection does not extend Connection. PooledConnection.close() must always close the actual physical connection to the database because PooledConnection is used by the connection pool itself. The Connection interface is used by the application and hence Connection.close() may close the connection or return it to a connection pool. JDBC drivers usually come with implementations of both interfaces where the Connection implementation wraps an instance of a PooledConnection implementation. Arguably, being able to formally declare which interface a particular close method belongs to is beneficial in cases like this.

NateDad 13y ago
I think this is really a problem that exists beyond interfaces. For example, even if you had these two concrete types, and both had close methods, how would you know when to call one close versus another and what they do? This kind of confusion is a perpetual problem... and I don't think Go interfaces make it any worse, really.
- fauigerzigerk 13y ago
  I would know because the concrete types formally reference an interface, and the documentation of the interface would tell me more about the intended semantics. You're right that simply having this formal reference doesn't solve all problems that could possibly arise. But there's one form of confusion that is much less likely to arise. As is so often the case, more flexibility comes with more opportunity for screw-ups.