Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang Object Oriented Design

nathany.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Golang Object Oriented Design

#41

Post by burntsushi »

mostafah wrote: post #6

One of the most common problems people have when they get to know Go is to not embrace its approach to programming, but try to enforce what they already know in Go programs. This is a clear example of that. Implementing “polymorphism” with Go interfaces is abusing interfaces! Seeing embedding as inheritance misses the point of both embedding and inheritance. Comparing packages to namespaces isn’t that bad, but just d…

Did you RTFA? The conclusion has:

> Composition, embedding and interfaces provide powerful tools for Object-Oriented Design in Go. Thinking in terms of inheritance really doesn't work. Trust me, I tried.

The OP is clearly trying to introduce ideas in Go by relating them to other ideas you might be more familiar with. This is, IMO, very much distinct from trying to shoehorn design techniques from other languages.

In fact, the OP is rather explicitly agreeing with your point and trying to remedy it.

> Implementing “polymorphism” with Go interfaces is abusing interfaces!

Go's interfaces use structural subtyping, which is a form of polymorphism.

Re: Golang Object Oriented Design

#42

Post by stonemetal »

herge wrote: post #39
nickpresta wrote: post #38

Earlier quoted context omitted.

http://golang.org/pkg/sort/#example_Interface

So the answer is yes, I have to implement the whole interface?

Yes, to use code that relies on an interface you must implement the interface for your types.

That is one of the reasons go has a guiding design principle that interfaces should be as small as possible.

Re: Golang Object Oriented Design

#43

Post by newgame »

fauigerzigerk wrote: post #20
qznc wrote: post #18

Earlier quoted context omitted.

Auto-completion aka -suggestion. Te first argument is usually a variable already declared one more more lines above your cursor, so you can start with that. Then your IDE kicks in and gives you a list of possible methods. In this case it is easy, if you want to use "length" or "size" for your list.

I see no reason why the IDE couldn't do that with multimethods. The trigger might have to be a little different but otherwise I see no issues here.

> The trigger might have to be a little different

The "dot-autocompletion" has a pretty good usability in my opinion. You write down the name of the variable, enter a dot and you get a filtered list of methods that "make sense" to call on the receiver (key word: discoverability of the API).

How exactly would one implement the trigger with multimethods? I think this is an important consideration to make from a usability standpoint.

Re: Golang Object Oriented Design

#44

Post by munificent »

masklinn wrote: post #28
adamlett wrote: post #27

Earlier quoted context omitted.

JavaScript and Self don't have classes, but they do have inheritance.

Self has delegation. Conflating delegation and inheritance is no better than conflating embedding and inheritance.

Delegation seems pretty similar to inheritance to me. What am I missing?

Re: Golang Object Oriented Design

#45

Post by munificent »

> To apply the uniform access principle to the Part type, we could change the struct definition and provide setter/getter methods

If you have to apply it, it isn't uniform access. The point of the principle is that the call-site shouldn't distinguish between getters and fields so that the implementer can change that decision freely without breaking callers.

Nice article, though!

Re: Golang Object Oriented Design

#46

Post by jlarocco »

newgame wrote: post #43
fauigerzigerk wrote: post #20

Earlier quoted context omitted.

I see no reason why the IDE couldn't do that with multimethods. The trigger might have to be a little different but otherwise I see no issues here.

> The trigger might have to be a little different The "dot-autocompletion" has a pretty good usability in my opinion. You write down the name of the variable, enter a dot and you get a filtered list of methods that "make sense" to call on the receiver (key word: discoverability of the API). How exactly would one implement the trigger with multimethods? I think this is an important consideration to make from a usabili…

Could swap the function name and argument list, so DoSomething(x,y,z) would become (x,y,z)DoSomething.

I admit it's a little weird, but not so weird people couldn't get used to it.

Re: Golang Object Oriented Design

#47

Post by ori_b »

4ad wrote: post #17
dualogy wrote: post #10

Earlier quoted context omitted.

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

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

Re: Golang Object Oriented Design

#48

Post by masklinn »

munificent wrote: post #44
masklinn wrote: post #28

Earlier quoted context omitted.

Self has delegation. Conflating delegation and inheritance is no better than conflating embedding and inheritance.

Delegation seems pretty similar to inheritance to me. What am I missing?

It doesn't set up is-a relationships and can be used for significantly more than differential inheritance (IIRC Self uses it for scoping).

Re: Golang Object Oriented Design

#49

Post by arethuza »

jlarocco wrote: post #46
newgame wrote: post #43

Earlier quoted context omitted.

> The trigger might have to be a little different The "dot-autocompletion" has a pretty good usability in my opinion. You write down the name of the variable, enter a dot and you get a filtered list of methods that "make sense" to call on the receiver (key word: discoverability of the API). How exactly would one implement the trigger with multimethods? I think this is an important consideration to make from a usabili…

Could swap the function name and argument list, so DoSomething(x,y,z) would become (x,y,z)DoSomething. I admit it's a little weird, but not so weird people couldn't get used to it.

It's not that weird - you've pretty much described what a function call would look like in a language that uses Reverse Polish e.g. PostScript

   x y x DoSomething
However, I don't think I've seen an IDE for PostScript or Forth

Re: Golang Object Oriented Design

#50

Post by discreteevent »

pjmlp wrote: post #2

For an understanding how to do OO design in Go, learning about component programming is a good way. http://www.amazon.de/Component-Software-Beyond-Object-Orient... The first edition used Component Pascal from the Oberon family, which Go gets some influence from. Later editions used Java and C# instead. Additional learning about how COM and XPCOM work is also a way to get some ideas.

Yes Go is similar to COM in that it focuses on interfaces and leaves out implementation inheritance which causes so much trouble. COM was way ahead of its time on that.

"Component Oriented Programming = Polymorphism + (Really) Late Binding + (Real, Enforced) Encapsulation + Interface Inheritance + Binary Reuse"

Apart from "Binary Reuse", the definition above is what object oriented programming is really all about (I think).

Post reply on HN