notes-computer-programming-programmingLanguageDesign-prosAndCons-structuralTyping

"

On Fri, Nov 13, 2009 at 7:52 PM, jqb <jqba...@gmail.com> wrote: > The point is that the language design suffers from insularity. In the > case of treating duck typing as something they invented, I would like > to *think* that it is merely insularity.

I don't think they claimed that, notably because it's *not* duck typing, it's structural conformance of implementations to interfaces. Which is of course not new either (and it wasn't ten years ago when we first published papers on it). I just hope they'll fix it to get rid of accidental conformance and of the old name clash problem, both of which can be avoided with fairly minor changes to the language.

...

They may not say it outright but they leave that impression. As to whether it's duck typing ... compatibility is determined statically, but it's based on method names; there's nothing "structural" about it, and I haven't seen any mention of the run-time cost of interface method calls. From http://en.wikipedia.org/wiki/Duck_typing:

"in a non-duck-typed language, one can create a function that takes an object of type Duck and calls that object's walk and quack methods. In a duck-typed language, the equivalent function would take an object of any type and call that object's walk and quack methods"

In Go, all you need to add to that is a local interface declaration. However you want to classify it technically, from a programmer's POV it walks and talks like duck typing. "