<story><title>Golang Object Oriented Design</title><url>http://nathany.com/good/</url></story><parent_chain><item><author>dualogy</author><text>Without method receivers you wouldn&amp;#x27;t have methods, only funcs. Then you&amp;#x27;d end up calling your &amp;quot;methods&amp;quot; names like `Address_Compare(addr1, addr2 Address)`, `Address_ToString(addr Address)` and so forth.&lt;p&gt;How unpleasant that&amp;#x27;d be! With method receivers, you can have `addr1.CompareTo(addr2)` and `addr.ToString()` etc..</text></item><item><author>fauigerzigerk</author><text>I keep wondering if Go couldn&amp;#x27;t have gone further in getting rid of the cruft that has accumulated around OO. Go doesn&amp;#x27;t have an implicit &amp;quot;this&amp;quot; pointer. It doesn&amp;#x27;t have members that are private to an individual object nor members private to a type. Encapsulation exists only at the package level.&lt;p&gt;Yet Go keeps that old OO concept of method receivers. Why? I never found it very plausible to have one special case parameter with its very own syntax, but with type level encapsulation it did at least have some justification.&lt;p&gt;Without this kind of encapsulation, the only remaining purpose of the receiver is method dispatch. But why dispatch based on the type of one parameter and not the others? Multimethods would have been the logical conclusion of the OO cleanup that Go&amp;#x27;s designers apparently intended to achieve.</text></item></parent_chain><comment><author>exDM69</author><text>&amp;gt; Without method receivers you wouldn&amp;#x27;t have methods, only funcs. Then you&amp;#x27;d end up calling your &amp;quot;methods&amp;quot; names like `Address_Compare(addr1, addr2 Address)`, `Address_ToString(addr Address)` and so forth.&lt;p&gt;Methods are just a limited special case of functions. Also, there are various different semantics that are used in function application. Your view of function application is rather limited, you might want to study e.g. how functions are applied in Haskell (type classes) or Common Lisp Object System (CLOS, multimethods). Both of them use very different semantics to what you&amp;#x27;re used to.&lt;p&gt;In addition, good namespacing and module systems can solve a big part of the &amp;quot;problem&amp;quot; you mention. Most modern languages have more than one giant global namespace.</text></comment>
<story><title>Golang Object Oriented Design</title><url>http://nathany.com/good/</url></story><parent_chain><item><author>dualogy</author><text>Without method receivers you wouldn&amp;#x27;t have methods, only funcs. Then you&amp;#x27;d end up calling your &amp;quot;methods&amp;quot; names like `Address_Compare(addr1, addr2 Address)`, `Address_ToString(addr Address)` and so forth.&lt;p&gt;How unpleasant that&amp;#x27;d be! With method receivers, you can have `addr1.CompareTo(addr2)` and `addr.ToString()` etc..</text></item><item><author>fauigerzigerk</author><text>I keep wondering if Go couldn&amp;#x27;t have gone further in getting rid of the cruft that has accumulated around OO. Go doesn&amp;#x27;t have an implicit &amp;quot;this&amp;quot; pointer. It doesn&amp;#x27;t have members that are private to an individual object nor members private to a type. Encapsulation exists only at the package level.&lt;p&gt;Yet Go keeps that old OO concept of method receivers. Why? I never found it very plausible to have one special case parameter with its very own syntax, but with type level encapsulation it did at least have some justification.&lt;p&gt;Without this kind of encapsulation, the only remaining purpose of the receiver is method dispatch. But why dispatch based on the type of one parameter and not the others? Multimethods would have been the logical conclusion of the OO cleanup that Go&amp;#x27;s designers apparently intended to achieve.</text></item></parent_chain><comment><author>masklinn</author><text>GP specifically mentioned multimethods and your comment is completely wrong when they&amp;#x27;re taken in account.&lt;p&gt;They would allow `ToString(attr)` to have one implementation per type, and `CompareTo(item1, item2)` to have one implementation per `(typeof item1, typeof item2)` pair. The latter being unavailable in Go, and only statically available in languages with overloading.</text></comment>