| ▲ | zbentley 2 days ago | |||||||||||||
How so? Genuine question. Duck typing is “try it and see if it supports an action”, where interface declaration is the opposite: declare what methods must be supported by what you interact with. In Python, that would be a Protocol (https://typing.python.org/en/latest/spec/protocol.html), which is a newer and leas commonly used feature than full, un-annotated duck typing. Sure, type checking in Python (Protocols or not) is done very differently and less strongly than in Go, but the semantic pattern of interface segregation seems to be equivalently possible in both languages—and very different from duck typing. | ||||||||||||||
| ▲ | cube2222 2 days ago | parent | next [-] | |||||||||||||
Duck typing is often equated with structural typing. You’re right that officially (at least according to Wikipedia) duck typing is dynamic, while structural is the same idea, but static. Either way, the thing folks are contrasting with here is nominal typing of interfaces, where a type explicitly declares which interfaces it implements. In Go it’s “if it quacks like a duck, it’s a duck”, just statically checked. | ||||||||||||||
| ▲ | sirsinsalot 2 days ago | parent | prev [-] | |||||||||||||
I'm saying that at some point declaring the minimal interface a caller uses, for example Reader and Writer instead of a concrete FS type, starts to look like duck typing. In python a functions use of v.read() or v.write() defines what v should provide. In Go it is compile time and Python it is runtime, but it is similar. In Python (often) you don't care about the type of v just that it implements v.write() and in an interface based separation of API concerns you declare that v.write() is provided by the interface. The aim is the same, duck typing or interfaces. And the outcome benefits are the same, at runtime or compile time. | ||||||||||||||
| ||||||||||||||