3 ms·

Good list. Regarding (4) Implicit interfaces -- to me, it's implicit interfaces that feel wrong :) Something having a method with a particular signature doesn

Good list. Regarding (4) Implicit interfaces -- to me, it's implicit interfaces that feel wrong :) Something having a method with a particular signature doesn't seem to me to be any kind of promise that it's intended to be used for the interface that expects that method. 'implements X', is a clear statement that yes, this method is made just for that specific interface. But this is just academic. I've never actually hit a situation yet where something just happens to implement an interface by chance, and does something completely unexpected.

deleted 4y ago
[deleted]
liampulles 4y ago
Here's what I do: ``` type Doer interface { Do() error } type CanDoer struct{} var _ Doer = &CanDoer{} // This ``` If CanDoer does not implement Doer, it will fail to compile, and you can quickly see what you need to do to fix.
- bheadmaster 4y ago
  I think the question is more in lines of "How do I know that CanDoer does what I expect of Doer to do, semantically?". In which case, it's impossible to know for sure. For example, I could create a type with a `Read([]byte) (int, error)` method that doesn't conform to the `io.Reader` expected behavior (e.g. reads from the byte array and returns an int if byte array contains a numeric string), yet I'd be able to pass it as an argument to a function that accepts `io.Reader` - the type system won't stop me, but the behavior will be broken. However, in practice, writing erroneous implementations of common interfaces is uncommon. Naming conventions are really important in Go, so the only way to abuse type system in this way is to abuse the naming conventions, which is already considered bad practice in any sane programming language.
  - Winsaucerer 4y ago
    Yep, this is exactly what I had in mind.
  - thwarted 4y ago
    How do you ensure that a language with explicit interfaces implements what the expected behavior is?
    - pjmlp 4y ago
      It is a kind of honour system, the developer has explicitly stated, yes I want to comply to interface XYZ, instead of doing it by accident and due to copy-paste error passing the wrong one, ensuring a couple of debugging hours tracking down where the error lies in code that compiles without any issues. Typical debugging problem in dynamic languages.
      - bheadmaster 4y ago
        > the developer has explicitly stated, yes I want to comply to interface XYZ, instead of doing it by accident To be honest, it's pretty hard to implement an interface by accident. You'd have to specifically implement methods with specific names and type signatures. If method names + type signatures don't intuitively specify how should implementation behave, then it's either a bad interface or a trivial one.
- peterashford 4y ago
  This is, IMO, clear indication of a lack in the language

deleted 4y ago

[deleted]

liampulles 4y ago

Here's what I do: ``` type Doer interface { Do() error } type CanDoer struct{} var _ Doer = &CanDoer{} // This ``` If CanDoer does not implement Doer, it will fail to compile, and you can quickly see what you need to do to fix.

bheadmaster 4y ago
I think the question is more in lines of "How do I know that CanDoer does what I expect of Doer to do, semantically?". In which case, it's impossible to know for sure. For example, I could create a type with a `Read([]byte) (int, error)` method that doesn't conform to the `io.Reader` expected behavior (e.g. reads from the byte array and returns an int if byte array contains a numeric string), yet I'd be able to pass it as an argument to a function that accepts `io.Reader` - the type system won't stop me, but the behavior will be broken. However, in practice, writing erroneous implementations of common interfaces is uncommon. Naming conventions are really important in Go, so the only way to abuse type system in this way is to abuse the naming conventions, which is already considered bad practice in any sane programming language.
- Winsaucerer 4y ago
  Yep, this is exactly what I had in mind.
- thwarted 4y ago
  How do you ensure that a language with explicit interfaces implements what the expected behavior is?
  - pjmlp 4y ago
    It is a kind of honour system, the developer has explicitly stated, yes I want to comply to interface XYZ, instead of doing it by accident and due to copy-paste error passing the wrong one, ensuring a couple of debugging hours tracking down where the error lies in code that compiles without any issues. Typical debugging problem in dynamic languages.
    - bheadmaster 4y ago
      > the developer has explicitly stated, yes I want to comply to interface XYZ, instead of doing it by accident To be honest, it's pretty hard to implement an interface by accident. You'd have to specifically implement methods with specific names and type signatures. If method names + type signatures don't intuitively specify how should implementation behave, then it's either a bad interface or a trivial one.
peterashford 4y ago
This is, IMO, clear indication of a lack in the language