[junke]

> ... would be to make those private fields visible in the method outside the package.

Since you write the implementation of the method inside your struct's package, you have the right to manipulate private data there as you would do with any function. I don't understand the problem.

[tqkxzugoaupvwqr]

I think the problem they wanted to avoid is incompatibility (Go cares much about compatibility, see Go 1’s Promise of Compatibility[1]). Private fields mean to external packages “This is non of your business. The field can change or be removed at any time without notice.”.

If external packages could add methods to a struct, thus turning private fields into effectively-public fields, the whole struct (all its fields) potentially becomes public. How do you maintain a package if your defined API (public fields/methods) is ignored and instead everything is made available to external packages? To keep compatibility, you could never refactor the package, instead you have to keep all private fields to not break external packages that use them.

[1] https://golang.org/doc/go1compat

[Xlythe]

You could just let the external methods only access public variables. That's exactly what Java let's you do when you extend another class. I agree that private members should stay private.

I wish I could add methods from outside of my package. I currently run into cyclical dependency issues when I try and define something like...

func (g Game) GetPlayers() []Player { ... }

func (p Player) GetGame() Game { ... }

While having Game and Player in separate packages. It's not the end of the world having them in the same package, but the amount of methods does pile up...

[junke]

There is no need to bring private fields too. Just keep the same visibility rules. The new method would be written inside a user package which would have access only to the public members of the type being dispatched on. That mean that you could only define methods for external structs that make use of their public API.