On Sat, 10 Dec 2016 02:37:24 -0800 (PST)
T L <tapir....@gmail.com> wrote:
[...]
> But the spec says a method M defined for type T is also a method of
> *T. In fact, it is not accurate. T.M and (*T).M have different
> signatures.
The spec does not say that.
What you state is your interpretation of the spec.
I think the confusion stems from the difference between what you think
method sets are there for and what Go designers intended them to be
there for. As I understand it, the point of defining the concept of
the methods sets is there to properly define Go's implicit
implementation of interfaces -- as opposed to defining some (imaginary)
set of rules dealing with "method sharing" between types T and *T.
So I interpret this part of the spec in a way along these lines:
| *T implicitly implements the interface formed by own methods of
| its "pair" type T.
This means we can do:
package main
type Doer interface {
Do()
}
type T struct{}
func (t T) Do() {
}
func fn(d Doer) {
d.Do()
}
func main() {
t := T{}
p := &T{}
fn(t)
fn(p)
}
Here, the function fn() expects anything which implements the Doer
interface, and the values of type T and *T are both fine to pass to it
because *T implements the method Do() of its pair type T.
--
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
