On Fri, Mar 10, 2017 at 7:19 AM, Henry wrote:
>
> Thanks for the reply. I will rephrase the question. See the code
> illustration in the first post if you did not follow the discussion from the
> beginning.
>
> a.Arg and b.Arg are identical interfaces living in different packages:
> package a and
>
> Thanks for the reply. I will rephrase the question. See the code
> illustration in the first post if you did not follow the discussion from
> the beginning.
>
Indeed, I've been following since you first posted so I saw that
illustration.
> a.Arg and b.Arg are identical interfaces living in d
Hi,
Thanks for the reply. I will rephrase the question. See the code
illustration in the first post if you did not follow the discussion from
the beginning.
a.Arg and b.Arg are identical interfaces living in different packages:
package a and package b respectively. Type X that implements a.Ar
As far as a.Worker and b.Worker not being identical, the relevant section
of the spec is:
https://golang.org/ref/spec#Type_identity
*Two interface types are identical if they have the same set of methods
> with the same names and identical function types. Lower-case method names
> from different
Let's suppose a.Worker and b.Worker both have method Work(c.Arg) where c.Arg is
a struct instead of an interface. The compiler now recognizes both a.Worker and
b.Worker as identical although both live in different packages. The code will
compile just fine.
I don't think it matters where the typ
The two type a.Arg and b.Arg are different type because the live in
different packages. Same for a.Worker and b.Worker. Different
packages --> different types. Laxing this rule would open a can of
worms: Suddenly your axis.Point and rating.Point become
assignable, just because the "are the same". L
