[majewsky]

I've never thought of that syntax as conveying a particular statement. They could also have done

  func *Receiver.method(arg int)

instead of

  func (r *Receiver) method(arg int)

The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I've come to like this design decision.

[icebraining]

The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I've come to like this design decision.

self, at least if you're talking about Python, is not a keyword, it's just a convention. You can use whatever your want.

[leshow]

It's not just python that uses self. Rust, for example, it's sugar for self: Self

[leaveyou]

He speaks about non-local receivers.

You can't have:

func (r *otherPackage.Receiver) method(arg int)

[literallycancer]

What's the issue with composing a new type that has otherPackage.Receiver in it, and defining the new method on the new type?

[leaveyou]

For me there is no issue.

[ptman]

I'm guessing: you still can't access unexported members (private vs Public).

[junke]

The question could be asked the opposite: why is the new type necessary?

[majewsky]

Because if you allow non-local method declarations, you have a ton of stuff to think about:

- Are these methods exported?

- If yes, how do you import them? Explicitly or implicitly?

- Given a method call, how can the developer tell where it was defined? How can she know if the same method call is available when using the same library in some other project? Remember that not everyone uses IDEs.

- etc.

I can see why the Go designers decided that it's just not worth it. I've seen how you turn a language into a mess with non-local method declarations (cough Ruby cough).