Hacker News Reader

Comment by dualogy | Hacker News Reader

Without method receivers you wouldn't have methods, only funcs. Then you'd end up calling your "methods" names like `Address_Compare(addr1, addr2 Address)`, `Address_ToString(addr Address)` and so forth.

How unpleasant that'd be! With method receivers, you can have `addr1.CompareTo(addr2)` and `addr.ToString()` etc..

View on HN

> Without method receivers you wouldn't have methods, only funcs. Then you'd end up calling your "methods" names like `Address_Compare(addr1, addr2 Address)`, `Address_ToString(addr Address)` and so forth.

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're used to.

In addition, good namespacing and module systems can solve a big part of the "problem" you mention. Most modern languages have more than one giant global namespace.

> 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)

Well, sure. On the other hand, if you had receivers for record accessors, you wouldn't end up with the ugly prefixing necessary in Haskell.

GP specifically mentioned multimethods and your comment is completely wrong when they're taken in account.

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.

With multimethods, that doesn't happen. You declare the compare multi (dispatch point), then you can declare as many compare methods as you want.

Not with higher order type inference (various MLs), but then you have function overloading and Go decided against function overloading.

/Edit: parallel comments mention multimethods. The difference is that with higher order type inference you can do static dispatch, but multimethods are dynamically dispatched AFAIK.

Type inference is not necessary. C++ provides function overloading as well.

Go has methods only to satisfy interfaces, which are different than most other language's interfaces and a very crucial part of what gives the feel of Go. No methods, no interfaces, therefore if Go were to have no methods, it would have to offer the same features and language feel by some other mechanism. Perhaps there are many ways to do that, but the only way I can think of is allowing for code like this:

  type IPConn struct {
  	ip Ip
  	// contains filtered or unexported fields
  }
  
  func Write(i IPCconn, buf []byte) (int, error) { /* implementation */ }
  
  type File struct {
  	name string
  	// contains filtered or unexported fields
  }
  
  func Write(f File, buf []byte) (int, error) { /* implementation */ }
  
  func WriteString(w T, s string) (int, error) {
  	return Write(w, []byte(s))
  }

Please note that there are no explicit interfaces, but WriteString takes an implicit Writer. You can do that in C++ with overloaded functions and templates (not overloaded functions alone), but templates are an example of higher order type inference, which was the point I was trying to convey.

I always thought of multimethods as something that dispatches based on both static (where available) and dynamic type information. But you may be right that PL researchers don't see it that way.

Type inference in the ML flavors doesn't work well with this at all. The multiple implementations of functions introduces ambiguity, which lead to multiple solutions to the type equations.

This leads to very hairy inference problems, which is why none of the ML family languages (that I know of) allow ad-hoc overloading of functions.

Multimethods don't have that problem.

AddressCompare seems good to me.

Until you have an IDE that has to infer what it applies to.

Your global namespace would be so incredibly polluted.

Reply on news.ycombinator.com