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?