One important difference is polymorphism/namespacing. If you have the types X,Y,Z, each of them could implement a Quack() method, while you would have to write a QuakX, QuakY, and QuakZ function, if you wanted to wanted to have the three different implementations. So the method approach looks and reads much cleaner, even if you do not plan to dispatch dynamically.
Peter On Sun, Mar 12, 2017 at 3:36 PM, <shaham...@gmail.com> wrote: > Please check https://grisha.org/blog/2016/09/22/golang-receiver-vs- > function/ > > > On Wednesday, March 2, 2016 at 1:04:55 AM UTC+5:30, Julio Guerra wrote: >> >> After all these years, this excellent question is still not clearly >> answered... This point of the language makes this design decision really >> unclear when beginning. Because method calls on method receivers are >> statically resolved, while method calls on arguments whose types are >> interfaces are dynamically dispatched and statically checked (compile-time >> error when the expected interface is not implemented). So this question >> really needs more attention and a more straightforward design rule. Mix in >> type embedding and you end up with a mental node >< >> > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
