On Thu, Jun 2, 2022 at 4:38 PM Deividas Petraitis <h...@deividaspetraitis.lt>
wrote:
> 1. Structs are for representing things, they are things
> 2. Funcs are for performing actions, calculating things
> 3. Methods for performing actions on thing state
> 4. Methods to satisfy interface
>
4 is really the *big* technical point. 3 is basically just aesthetics.
> However if I would want for example to implement some kind of interface I
> would be forced to use method over func, but it looks weird to me for some
> reason:
>
> ```
> interface BMICalculator {
> CalculateBMI() float32
> }
>
> // Satisfies BMICalculator
> func (p * Person) CalculateBMI() float32 {
> return p.weight / (p.height * p.height) x 703
> }
> ```
>
What looks weird about this? Seems pretty straight forward.
Leaving aside whether that's a sensible use of interfaces, but assuming
there is such an interface…
>
> For example when looking at this STD code I am not longer to reason about
> choices funcs vs methods based on points above:
> https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;l=26;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708
>
> Why `(a
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708;bpv=1;bpt=1;l=26?gsn=a&gs=kythe%3A%2F%2Fgo.googlesource.com%2Fgo%3Flang%3Dgo%3Fpath%3Dnet%23param%2520TCPAddr.family%253Aa>
> *TCPAddr
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=21>
> ) family
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708;bpv=1;bpt=1;l=26?gsn=family&gs=kythe%3A%2F%2Fgo.googlesource.com%2Fgo%3Flang%3Dgo%3Fpath%3Dnet%23method%2520TCPAddr.family>()`
> is implemented as a method when it can be implemented as pure func like:
>
Aesthetics. It's code that is specific to that type. By making it a method,
it makes the encapsulation clear. You can enforce a convention that only
methods access unexported fields of a type directly. And it splits up the
namespace. If multiple types have a `family` method, you don't have to
overload that name as `tcpFamily`, `udpFamily`… but instead tie the name to
the type without having it in the package scope.
But yes, there is no *technical* reason why you couldn't make it a
function. The language makes no distinction there, except for interface
satisfaction.
>
> ```
> func Family
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708;bpv=1;bpt=1;l=26?gsn=family&gs=kythe%3A%2F%2Fgo.googlesource.com%2Fgo%3Flang%3Dgo%3Fpath%3Dnet%23method%2520TCPAddr.family>
> (a
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708;bpv=1;bpt=1;l=26?gsn=a&gs=kythe%3A%2F%2Fgo.googlesource.com%2Fgo%3Flang%3Dgo%3Fpath%3Dnet%23param%2520TCPAddr.family%253Aa>
> *TCPAddr
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=21>)
> int
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708;bpv=1;bpt=1;l=26?gsn=int&gs=kythe%3A%2F%2Fgo.googlesource.com%2Fgo%3Flang%3Dgo%23int%2523builtin>
> {
> if a
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=26>
> == nil || len(a
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=26>
> .IP
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=22>)
> <= IPv4len
> <https://cs.opensource.google/go/go/+/master:src/net/ip.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=22>
> {
> return syscall <http://godoc.org/syscall>.AF_INET
> <https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=26>
> }
> if a
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=26>
> .IP
> <https://cs.opensource.google/go/go/+/master:src/net/tcpsock.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=22>
> .To4
> <https://cs.opensource.google/go/go/+/master:src/net/ip.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=211>()
> != nil {
> return syscall <http://godoc.org/syscall>.AF_INET
> <https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=26>
> }
> return syscall <http://godoc.org/syscall>.AF_INET6
> <https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;drc=46ab7a5c4f80d912f25b6b3e1044282a2a79df8b;l=27>
> }
> ```
>
> So using reasoning above based on silly example looks O.K. but I seems
> that I might be still missing some kind of context/information because I
> can't explain example from STD.
>
> I would like to see what other people approaches this "problem" and to
> learn is there any other rules/guidelines to follow.
>
> Cheers, Deividas
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b4424465-ea36-4863-8ccf-3631de4ab56an%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/b4424465-ea36-4863-8ccf-3631de4ab56an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE72M%2BzPKFucJcYWRap5%2BSY7bCXsM8%2BLmbmy6uL1-LU1A%40mail.gmail.com.
