4 ms·

I'm not a massive fan of duck typing, but it's literally never even occurred to me to worry about the concern addressed in this article (that an object accident

I'm not a massive fan of duck typing, but it's literally never even occurred to me to worry about the concern addressed in this article (that an object accidentally conforms to an interface and is used as such).

andyferris 4y ago
Interesting. Can I ask, what are the things you don't like about duck typing then?
- mikebenfield 4y ago
  One major thing I like about having to implement a defined interface is that it forces people creating an API to actually define what that interface is. And in typing out that interface there's a fair chance they'll actually write doc comments. IME a lot of libraries that do duck-typing (for instance Python) make very little effort to explain what methods I'm supposed to implement or what the contract is supposed to be for those methods. It also forces users of the API to explicitly state in code that they're intending to implement that interface, as opposed to just implementing a handful of seemingly random methods whose purpose will not be immediately clear to readers. Also, AFAICT duck typing is incompatible with the approach taken in Rust or Haskell where the definition of a type can be decoupled from its implementation of various interfaces (called traits in Rust or type classes in Haskell), and where methods or attributes in different interfaces implemented for the same type can have the same name and not clash, because the object isn't the namespace for its methods. I strongly prefer this approach.
  - eyelidlessness 4y ago
    > One major thing I like about having to implement a defined interface is that it forces people creating an API to actually define what that interface is. And in typing out that interface there's a fair chance they'll actually write doc comments. This has another interesting beneficial side-effect, when embraced: it often leads not just to better API design, but better design in general. Defining an interface necessarily means thinking about it. Which in turn generally leads to thinking about how it’s consumed, at least a fuzzy picture of the code implementing it. All of which can also percolate out into other parts of a system.

andyferris 4y ago

Interesting. Can I ask, what are the things you don't like about duck typing then?

mikebenfield 4y ago
One major thing I like about having to implement a defined interface is that it forces people creating an API to actually define what that interface is. And in typing out that interface there's a fair chance they'll actually write doc comments. IME a lot of libraries that do duck-typing (for instance Python) make very little effort to explain what methods I'm supposed to implement or what the contract is supposed to be for those methods. It also forces users of the API to explicitly state in code that they're intending to implement that interface, as opposed to just implementing a handful of seemingly random methods whose purpose will not be immediately clear to readers. Also, AFAICT duck typing is incompatible with the approach taken in Rust or Haskell where the definition of a type can be decoupled from its implementation of various interfaces (called traits in Rust or type classes in Haskell), and where methods or attributes in different interfaces implemented for the same type can have the same name and not clash, because the object isn't the namespace for its methods. I strongly prefer this approach.
- eyelidlessness 4y ago
  > One major thing I like about having to implement a defined interface is that it forces people creating an API to actually define what that interface is. And in typing out that interface there's a fair chance they'll actually write doc comments. This has another interesting beneficial side-effect, when embraced: it often leads not just to better API design, but better design in general. Defining an interface necessarily means thinking about it. Which in turn generally leads to thinking about how it’s consumed, at least a fuzzy picture of the code implementing it. All of which can also percolate out into other parts of a system.