code review 6500092: faq: go does not have duck typing

faq: go does not have duck typing

[r, 2012-09-07 18:50:57]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[0xjnml, 2012-09-07 19:42:26]

On Fri, Sep 7, 2012 at 8:50 PM,  <r@golang.org> wrote:

'By the way, Go does not have "duck typing", ...'

Nice to see this has become finally officially sourced.

-j

[iant, 2012-09-07 20:06:11]

https://codereview.appspot.com/6500092/diff/3001/doc/go_faq.html
File doc/go_faq.html (right):

https://codereview.appspot.com/6500092/diff/3001/doc/go_faq.html#newcode556
doc/go_faq.html:556: By the way, Go does not have "duck typing", which is a
looser, more dynamic concept.
I'm not entirely convinced we need this paragraph.

[r, 2012-09-07 20:17:58]

I could drop it and keep just the s/duck/structural/. The reason I
added this paragraph was that it's commonly and incorrectly stated
that Go has duck typing and clearing that up seems a fine thing to do
in the FAQ.

-rob

[iant, 2012-09-07 20:19:28]

LGTM

I'm ambivalent.

[r, 2012-09-07 20:20:24]

On Fri, Sep 7, 2012 at 1:19 PM,  <iant@golang.org> wrote:
> LGTM
>
> I'm ambivalent.

Understood. So am I. I'll hold off until others have a chance to reply.

-rob

[0xjnml, 2012-09-07 20:28:03]

On Fri, Sep 7, 2012 at 10:06 PM,  <iant@golang.org> wrote:
>
> https://codereview.appspot.com/6500092/diff/3001/doc/go_faq.html
> File doc/go_faq.html (right):
>
> https://codereview.appspot.com/6500092/diff/3001/doc/go_faq.html#newcode556
> doc/go_faq.html:556: By the way, Go does not have "duck typing", which
>
> is a looser, more dynamic concept.
> I'm not entirely convinced we need this paragraph.

a := "1"
b := 2
c := a + b // just fine

*is* duck typing.

...trying to convince you.

-j

[adonovan, 2012-09-07 20:51:21]

On 7 September 2012 16:28, Jan Mercl <0xjnml@gmail.com> wrote:
> a := "1"
> b := 2
> c := a + b // just fine
>
> *is* duck typing.

Well, duck typing has no official definition, but your code can be
viewed as a type-overloaded + operator (in a typed language such as
Java) or a dynamically dispatched + operator (in Python).  I wouldn't
call either duck typing.

I think duck typing more commonly refers to the idea of implicit
structural subtyping: you don't need to declare a relationship between
the impl and the interface when you define the impl, but if it has all
the right operations, you can use it.  By that definition, Go has it.

C++ has (arguably) a form of duck typing in template instantiation:
the template imposes a set of constraints (a "concept") and a type may
"model" that concept, but you don't have to declare that the type
models the concept.  In fact the concept may be conceived after the
type has been shipped.

All of which says to me that it's probably a phrase best avoided. ;)

[r, 2012-09-07 20:53:18]

Hello golang-dev@googlegroups.com, 0xjnml@gmail.com, iant@golang.org,
adonovan@google.com (cc: golang-dev@googlegroups.com),

Please take another look.

[iant, 2012-09-07 20:55:12]

On 2012/09/07 20:51:21, adonovan wrote:
> 
> I think duck typing more commonly refers to the idea of implicit
> structural subtyping: you don't need to declare a relationship between
> the impl and the interface when you define the impl, but if it has all
> the right operations, you can use it.  By that definition, Go has it.
> 
> C++ has (arguably) a form of duck typing in template instantiation:
> the template imposes a set of constraints (a "concept") and a type may
> "model" that concept, but you don't have to declare that the type
> models the concept.  In fact the concept may be conceived after the
> type has been shipped.

I don't agree that you are describing duck typing.  I think that duck typing
permits calling a method on a value without any prior arrangement at all. 
Neither Go nor C++ permit that.  Both Go and C++ require a conversion to an
appropriate type before calling the method.

> All of which says to me that it's probably a phrase best avoided. ;)

I agree with that.

Ian

[iant, 2012-09-07 20:55:30]

LGTM

[aram, 2012-09-07 21:00:09]

LGTM

Finally. Thanks.

[r, 2012-09-07 21:01:06]

*** Submitted as http://code.google.com/p/go/source/detail?r=d3d3e0825dd2 ***

faq: go does not have duck typing

R=golang-dev, 0xjnml, iant, adonovan, aram
CC=golang-dev
http://codereview.appspot.com/6500092

[0xjnml, 2012-09-07 21:06:00]

On Fri, Sep 7, 2012 at 10:51 PM, Alan Donovan <adonovan@google.com> wrote:
> On 7 September 2012 16:28, Jan Mercl <0xjnml@gmail.com> wrote:
>> a := "1"
>> b := 2
>> c := a + b // just fine
>>
>> *is* duck typing.
>
> Well, duck typing has no official definition, but your code can be
> viewed as a type-overloaded + operator (in a typed language such as
> Java) or a dynamically dispatched + operator (in Python).  I wouldn't
> call either duck typing.
>
> I think duck typing more commonly refers to the idea of implicit
> structural subtyping: you don't need to declare a relationship between
> the impl and the interface when you define the impl, but if it has all
> the right operations, you can use it.  By that definition, Go has it.
>
> C++ has (arguably) a form of duck typing in template instantiation:
> the template imposes a set of constraints (a "concept") and a type may
> "model" that concept, but you don't have to declare that the type
> models the concept.  In fact the concept may be conceived after the
> type has been shipped.
>
> All of which says to me that it's probably a phrase best avoided. ;)

It looks like I was a bit too much concise...

The code in question is the hypothetically valid Go code (would Go
have duck typing). The point it tried to communicate was that both 'a'
and 'b' do/easily may have statically determined types (== status
quo), but 'c' wouldn't (unless resorted to 'interface{}, which is the
only case of "anything"' in Go, but still not "duck typing" as the '+'
['-'/...] is not [duck "typingly"] working with 'interface{}')

-j

[rsc, 2012-09-10 16:20:13]

LGTM

Hard to care much about precise definitions. If it quacks like duck
typing, it's duck typing.

[mortdeus, 2012-09-28 21:19:28]

On 2012/09/10 16:20:13, rsc wrote:
> LGTM
> 
> Hard to care much about precise definitions. If it quacks like duck
> typing, it's duck typing.

The difference between structural typing and duck typing is that duck typing
observes the object being passed in as an argument at runtime.

Structural typing is static and therefore very different when you consider
things you cant do with go's interfaces. The primary example for python is
monkey patching. I.E. hot patching python source further ahead in the path of
your codes execution with a different type depending on which way the code's
execution flows.

So in the perspective of the runtime, how you look at Go's interfaces, and
python's duck type is alot different. Python's types look like a duck, walks
like a duck, and quacks like a duck when its encountered, so ill assume its a
duck. This is alot different than an interface with a big sign on it that says
"Certified 100% Authentic Duck -Gopher Type Introspective Association". :)