On Thu, Jun 2, 2022 at 4:38 PM Deividas Petraitis <h...@deividaspetraitis.lt>
wrote:
> Background: when I am writing code mostly I end up with some clunky
> solutions I am not happy with and one of the reasons I think is that I
> might be mixing funcs vs methods.
>
>
Squint your eyes enough, and methods are just a special kind of function.
One where a specific parameter is "implicit", "environmental",
"contextual", or "given."
The key insight is that methods are bound to types, as Jan writes. The
second insight is that they let the type vary. Imagine you had something
like
var a *TcpAddr
...
family(a)
vs
var a *TcpAddr
...
a.family()
If you change the `var a...` line to a new type, the former code also has
to change to a different function call, whereas the latter code would work
as long as the new type implements a `family()` method. Interfaces makes
this idea more viable, and empowers the reader and compiler further.
Aside from compiler technicalities, it's also a great classifier tool. We
should write programs in a dialogue with the compiler, and the compiler
should guide us to what the valid programs are. A method is a strong hint
that a computation belongs to a given type, and should be considered in the
context of said type. This allows humans and compilers to filter the set of
applicable calls down to the method set in the given context, which is
often a fraction of all possibilities.
--
J.
--
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/CAGrdgiW4vVR-s867Lu3yTKHEceN7DtbAJ10dm-FQc_8%3DHrq7hw%40mail.gmail.com.
