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

51–60 of 75 posts

Re: Golang Object Oriented Design

#51

Post by noelherrick »

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 done my work since the code won't compile if a class that extends an interface fails to implement all the methods.

Re: Golang Object Oriented Design

#52

Post by mercurial »

exDM69 wrote: post #35
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..

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

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

Re: Golang Object Oriented Design

#53

Post by ori_b »

Touche wrote: post #4

Is there any advantage to using OO in a language that doesn't have classes or inheritance? Does declaring a method on a type give you something that declaring a function that takes the type as an argument doesn't?

Yes. It gives you Liskov substitution.

Re: Golang Object Oriented Design

#54

Post by gmi01 »

noelherrick wrote: post #51

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…

To verify that Concrete implements Interface use this:

var _ Interface = Concrete{}

Re: Golang Object Oriented Design

#55

Post by lnmx »

noelherrick wrote: post #51

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…

The compiler will complain if you attempt to assign (or assert) a value to an interface that it cannot fulfill.

ex. http://play.golang.org/p/OLTHIXjgy8

Re: Golang Object Oriented Design

#56

Post by draegtun »

patrickg wrote: post #33
pjmlp wrote: post #26

Earlier quoted context omitted.

There are many ways to implement OO. Self, JavaScript, CLOS, Go, BETA, Clojure Protocols, Type Classes, COM and probably quite a few others. What most mainstream developers know, is not the only way.

+1 for mentioning BETA. Any actual user of that language?

BETA did come up in this HN post from last year: The impoliteness of overriding methods - https://news.ycombinator.com/item?id=4943538

Re: Golang Object Oriented Design

#57

Post by yoklov »

patrickg wrote: post #33
pjmlp wrote: post #26

Earlier quoted context omitted.

There are many ways to implement OO. Self, JavaScript, CLOS, Go, BETA, Clojure Protocols, Type Classes, COM and probably quite a few others. What most mainstream developers know, is not the only way.

+1 for mentioning BETA. Any actual user of that language?

No, but the Racket OO system is based on BETA's implementation of OO, and Racket has some actual users. There's definitely some interesting ideas there.

For example, `inner` being the opposite of super (e.g. call the subclasses implementation of this method). Some others, but I'm not sure I remember them (Augmentation?).

Re: Golang Object Oriented Design

#58

Post by dragonwriter »

Touche wrote: post #4

Is there any advantage to using OO in a language that doesn't have classes or inheritance? Does declaring a method on a type give you something that declaring a function that takes the type as an argument doesn't?

> Is there any advantage to using OO in a language that doesn't have classes or inheritance?

Yes. Really, interfaces are all you need for OO; class are just types-that-also-define-interfaces, and inheritance is just a shortcut for interface implementation.

While I think Go's implicit interface implementation is pretty much 180-degrees off the best way to do OO w/o classes and inheritance (I'd prefer explicit interface implementation, which eliminates interface collision), I do think clasess and inheritance get in the way more than they help.

Re: Golang Object Oriented Design

#59

Post by Arnor »

fauigerzigerk wrote: post #34
patrickg wrote: post #23

Earlier quoted context omitted.

I think that's how interfaces work. You define an interface by the methods a receiver has (a struct complying to the ReadCloser interface for example must implement Read() and Close()). While one has to get used to it, it works very nicely in practice.

I don't think so. Interfaces dispatch based on the type of the one and only special purpose receiver.

I've read this sentence 6 times and have no idea what it means...

Re: Golang Object Oriented Design

#60

Post by nostrademons »

fauigerzigerk wrote: post #5

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…

Interfaces with multiple dispatch would basically be Haskell typeclasses.

Typeclasses have a lot of tricky corner cases in defining their semantics, they're hard to type-inference (Haskell's type system is undecidable in some cases), and they lead to a lot of confusion for new programmers trying to learn the language. MPTCs were deliberately not standardized in Haskell 2010, because the design space around them hasn't been fully explored, and SPJ's feeling was that Associated Types might be a better solution for the problems involved.

Go's designers have decided to focus on pragmatism over power (wisely, IMHO - I quibble with a lot of the other aspects of Go's language design, but not this one), and the result is that they get about 85% of the power of multimethods/typeclasses with about 10% of the headaches.

Post reply on HN