Live data from Hacker News

Golang Object Oriented Design

nathany.com

71–75 of 75 posts

Re: Golang Object Oriented Design

#71

Good article - this covers the basic OO patterns in Go. I really like the simplicity of the design - objects are just structs and you can define a method for that object. Coming from C#, it's like every method is an extension method. The only critique I have is that there's no way to verify that object X implements methods A, B, and C. When I'm using C# or Java, I often use an interface as a test to make sure I've do…

"Compared to duck typing, interfaces are statically checked and documented through their declaration..."

Re: Golang Object Oriented Design

#72

I keep wondering if Go couldn't have gone further in getting rid of the cruft that has accumulated around OO. Go doesn't have an implicit "this" pointer. It doesn't have members that are private to an individual object nor members private to a type. Encapsulation exists only at the package level. Yet Go keeps that old OO concept of method receivers. Why? I never found it very plausible to have one special case parame…

Instead of starting with methods, start from interfaces. An interface is an object along with a collection of functions that have the same object as one of their parameters. It's a whole lot easier to implement if that special parameter is always in the same position.

Methods are useful for implementing interfaces and for avoiding namespace clutter; otherwise they're equivalent to functions.

I have no idea how you get from multimethods to interfaces.

Re: Golang Object Oriented Design

#73
post #69

Off-topic, but it would be nice if the blog didn't use 24-pixel body type , so that I could see more than a handful of lines at a time on my laptop. I've never seen a book with 24-point body type, except possibly for the visually impaired or 3-year-olds. Heck, most headings aren't even 24 point. What is it with this blog trend of gargantuan type, which seems increasingly common? It's totally out of proportion with th…

Off-topic: You'll be disappointed to learn that I also use an 18-pt font in my editor. I happen to like big readable text, maybe something to do with my age and my prescription being -5.5. P.S. the font-size is actually 1.5rem

34yo, -9.5 here, and I prefer 10pt fonts for code.

Do you not wear your glasses and/or contacts when working? I don't follow.

Re: Golang Object Oriented Design

#74
post #69

Earlier quoted context omitted.

Off-topic: You'll be disappointed to learn that I also use an 18-pt font in my editor. I happen to like big readable text, maybe something to do with my age and my prescription being -5.5. P.S. the font-size is actually 1.5rem

34yo, -9.5 here, and I prefer 10pt fonts for code. Do you not wear your glasses and/or contacts when working? I don't follow.

This preference could also depend on the font and what's rendering it; on my Thunderbolt Display, while "18pt" Consolas renders at less than 7 points wide using OS X defaults, Windows 8, using defaults for the same display, renders the same font at around 8.5 points wide by default, and Myriad Pro's "M" at nearly 13 points wide. Since 13/7 is approximately 18/10, your respective preferences may not be as different as you think.

Re: Golang Object Oriented Design

#75
post #19
post #17

Earlier quoted context omitted.

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.
Post reply on HN