On Saturday, December 10, 2016 at 7:08:01 PM UTC+8, Konstantin Khomoutov
wrote:
>
> On Sat, 10 Dec 2016 02:37:24 -0800 (PST)
> T L <tapi...@gmail.com <javascript:>> 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.
>
Yes, I know the rules.
I still think my interpretation in my 3rd comment is a better explanation.
--
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.
