Book: Incorrect description of "duck typing"

[mikebenfield]

2018 edition

Chapter 17, section 2 says: "is similar to the concept duck typing in dynamically typed languages: if it walks like a duck and quacks like a duck, then it must be a duck!"

But trait objects are nothing like duck typing, and describing trait objects with this term is potentially very confusing. The term "duck typing" was coined specifically to contrast with behavior like Rust's trait objects (or like Java's interfaces). In a language like Python, if you want to call x.f(), all that matters is that x is some object that implements a method named f. That's what duck typing is. In Rust or Java, if you want to call x.f(), you need to have in mind some specific trait object (or interface) that f belongs to, and x must implement that interface or trait. That's exactly what duck typing is not.

[carols10cents]

We disagree -- with traits, you don't need to know the concrete type, you only need to know the methods it will have. Duck typing also means you don't need to know the concrete type, and that is the similarity we're trying to draw. We've discussed this previously.

[mikebenfield]

So be it, but (with all due respect) you are simply incorrect. You're using the term "duck typing" as if it meant "dynamic dispatch." Which it doesn't, and if it did, what good is it to have the two different terms anyway?

[leventov]

@carols10cents the comparison with duck typing is not incorrect, but it seems to be very random at the place, if not provocative (because of what Michael wrote: "The term "duck typing" was coined specifically to _contrast_ with behavior like Rust's trait objects (or like Java's interfaces)." If you want to make some comparison, why wouldn't you mention interfaces from C# or Java, or abstract classes from C++, that are much closer to Rust's trait objects in this context?