From fb2758167f99fbf373396e8f957d20a21b51e03a Mon Sep 17 00:00:00 2001
From: Andrew Gerrand
Date: Mon, 5 Apr 2010 18:17:08 +1000
Subject: [PATCH] programming_faq: added question on T vs *T method sets
Adding this question on Russ' recommendation - not sure if
there is some detail here I'm missing.
The associated discussion was:
http://groups.google.com/group/golang-nuts/t/ec6b27e332ed7f77
R=rsc, r
CC=golang-dev
https://golang.org/cl/887042
---
doc/go_programming_faq.html | 38 ++++++++++++++++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/doc/go_programming_faq.html b/doc/go_programming_faq.html
index ecb64983c76..3c4f0e1ba6c 100644
--- a/doc/go_programming_faq.html
+++ b/doc/go_programming_faq.html
@@ -125,7 +125,43 @@ should recognise such cases and optimize its use of OS threads. For now,
-Closures
+Functions and Methods
+
+
+Why do T and *T have different method sets?
+
+
+From the Go Spec:
+
+
+
+The method set of any other named type T
consists of all methods
+with receiver type T
. The method set of the corresponding pointer
+type *T
is the set of all methods with receiver *T
or
+T
(that is, it also contains the method set of T
).
+
+
+
+If an interface value contains a pointer *T
,
+a method call can obtain a value by dereferencing the pointer,
+but if an interface value contains a value T
,
+there is no useful way for a method call to obtain a pointer.
+
+
+
+If not for this restriction, this code:
+
+
+
+var buf bytes.Buffer
+io.Copy(buf, os.Stdin)
+
+
+
+would copy standard input into a copy of buf
,
+not into buf
itself.
+This is almost never the desired behavior.
+
Why am I confused by the way my closures behave as goroutines?