Re: Duck Typing?

[William Ahern <william@...>]

On Tue, Jul 31, 2018 at 12:17:08PM -0400, Rena wrote:
<snip>
> To try to explain it simply (assuming I understand it correctly): you don't
> check that an object is of a given type, just that it can do what you want.
> You tell it to go over there, and you don't care if it's a duck and flies
> there, or a cat and walks there. The idea being that you don't need to know
> about all the different types of objects there are; you just assume they
> have a "go_there" method, and if not, either you do something else or you
> complain that you can't use this object. "If it quacks like a duck, that's
> good enough for me."
> 
> For a real life example: you're given a data source and you use its `read`
> method to get data. It doesn't matter if that source is a file, a socket, a
> function, etc; all that matters is that you can call its `read` method and
> get some data back. If you explicitly check that it's a file, then I can't
> use a socket instead, even if it would have worked just fine.
> 
> In more strictly typed languages, this would be done by accepting any
> object that inherits from some base class or implements some interface,
> which guarantees it has a `read` method. In a dynamically typed language
> like Lua, you don't get the advantage of type safety (you might receive an
> incompatible object), but the code can be much simpler (you don't have to
> import class definitions and try to fit your object into them).

The cousin to duck typing in statically typed languages is structural
typing. In those systems you need neither a shared class nor a shared
interface, if by interface you mean an abstract type declaration on the
referent object. (The proximity with "base class" made it seem--noscitur a
sociis--as if you had Java-like OOP interfaces in mind, rather than the
looser meaning in duck and structural typing.)