Hacker News Reader

Comment by suchabag | Hacker News Reader

> Authors of Go wanted to give users more flexibility by allowing them to add their logic to any structs they like. Even to the ones they’re not authors of (like some external libraries).

Except that you can't. "You "cannot define new methods on non-local type[s],". You have to compose them. That makes the struct function definition syntax a bit moot in my opinion.

View on HN

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.

He speaks about non-local receivers.

You can't have:

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

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

For me there is no issue.

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

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).

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

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.

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

Yes, you're right. I was somehow convinced that this is possible. Which is BTW not a good idea anyway (or at least I really don't like similar concept in Ruby - monkey patching).

Do you know why Go authors decided to put method definitions outside types definitions? Technically I don't see anything to stop the syntax from supporting the otherwise.

Reply on news.ycombinator.com