anonymously embedded in Y, then Y will have the method set of X, and *Y
will have the method set of *X?
On Friday, August 28, 2015 at 3:54:52 PM UTC-7, James Aguilar wrote:
You can make a Y out of a *X, but not an X. This is because X does not
implement Lock, since (*sync.Mutex).Lock() has a pointer receiver.
If you assign X{} to a variable, that variable's type is X. This variable
will not be assignable to a Y, since, as discussed, it does not implement
Lock(). If you assign &X{} to a variable, its type is *X.
Maybe it would help you understand if you wrote out the types?
http://play.golang.org/p/RJcw2jSPPF
-- James
--On Friday, August 28, 2015 at 1:11:23 PM UTC-7, Gbr wrote:
Ok, aha moment I hope ...
That has been my understanding. But, it is not quite complete, though in
hindsight the missing bit does seem obvious.
That "decision of whether X implements Y" is evaluated only at the point
of assignment. That makes it sound like a run-time evaluation, but Go
apparently evaluates it at compile-time and at every assignment that
depends on whether X implements Y. Different assignments -- pointer or
value -- can result in different evaluations of whether X implements Y.
Absent an assignment, there is simply no relationship between X and Y -- Go
has no 'extends' or 'implements'.
So, no spooky action at a distance - the variable assignment is the
action.
Not really. Let's try again from the top:Ok, aha moment I hope ...
On Friday, August 28, 2015 at 12:31:55 AM UTC-7, Jesse McNelis wrote:
There is no spooky at a distance action. The decision about whether a
type implements an interface is based on the type's method set.
http://golang.org/ref/spec#Method_sets
There is no spooky at a distance action. The decision about whether a
type implements an interface is based on the type's method set.
http://golang.org/ref/spec#Method_sets
That has been my understanding. But, it is not quite complete, though in
hindsight the missing bit does seem obvious.
That "decision of whether X implements Y" is evaluated only at the point
of assignment. That makes it sound like a run-time evaluation, but Go
apparently evaluates it at compile-time and at every assignment that
depends on whether X implements Y. Different assignments -- pointer or
value -- can result in different evaluations of whether X implements Y.
Absent an assignment, there is simply no relationship between X and Y -- Go
has no 'extends' or 'implements'.
So, no spooky action at a distance - the variable assignment is the
action.
You can make a Y out of a *X, but not an X. This is because X does not
implement Lock, since (*sync.Mutex).Lock() has a pointer receiver.
If you assign X{} to a variable, that variable's type is X. This variable
will not be assignable to a Y, since, as discussed, it does not implement
Lock(). If you assign &X{} to a variable, its type is *X.
Maybe it would help you understand if you wrote out the types?
http://play.golang.org/p/RJcw2jSPPF
-- James
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
