Golang Object Oriented Design • Hacker News Board

Re: Golang Object Oriented Design

#31

Post by masklinn » Mon, Sep 16, 2013, 1:13 PM UTC

dualogy wrote: post #10

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…

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

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.

Re: Golang Object Oriented Design

#32

Post by laumars » Mon, Sep 16, 2013, 1:16 PM UTC

qznc wrote: post #22

laumars wrote: post #9

Earlier quoted context omitted.

The lack of inheritance and creation methods are a bit annoying at times (particularly the latter), but there's still benefits of adopting an OOP approach in Go. For example, say you're writing a CMS and want to make strings like the article title to be used in the URL (for readable URLs and SEO), displayed in HTML (eg inside heading tags) and also potentially used for string comparisons, you'd need to have a functio…

The last line was probably intended as fmt.Println(html.EscapeString(article_title))

You're right, it was. I'll correct that now.

Re: Golang Object Oriented Design

#33

Post by patrickg » Mon, Sep 16, 2013, 1:25 PM UTC

pjmlp wrote: post #26

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?

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?

Re: Golang Object Oriented Design

#34

Post by fauigerzigerk » Mon, Sep 16, 2013, 1:26 PM UTC

patrickg wrote: post #23

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…

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.

Re: Golang Object Oriented Design

#35

Post by exDM69 » Mon, Sep 16, 2013, 1:28 PM UTC

dualogy wrote: post #10

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…

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

Re: Golang Object Oriented Design

#36

Post by pjmlp » Mon, Sep 16, 2013, 1:30 PM UTC

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?

I got to learn about it when I attended ECOOP'99.

Never saw it outside the conference.

Re: Golang Object Oriented Design

#37

Post by herge » Mon, Sep 16, 2013, 1:54 PM UTC

I have a question about go. Let's say I have a struct Foo and a function/method for Less. What is the quickest way to sort an array of Foo's?

Do I have to implement my own []Foo type with all three methods as described in the sort package?

Re: Golang Object Oriented Design

#38

Post by nickpresta » Mon, Sep 16, 2013, 2:02 PM UTC

herge wrote: post #37

I have a question about go. Let's say I have a struct Foo and a function/method for Less. What is the quickest way to sort an array of Foo's? Do I have to implement my own []Foo type with all three methods as described in the sort package?

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

Re: Golang Object Oriented Design

#39

Post by herge » Mon, Sep 16, 2013, 2:04 PM UTC

nickpresta wrote: post #38

herge wrote: post #37

I have a question about go. Let's say I have a struct Foo and a function/method for Less. What is the quickest way to sort an array of Foo's? Do I have to implement my own []Foo type with all three methods as described in the sort package?

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

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

Re: Golang Object Oriented Design

#40

Post by luikore » Mon, Sep 16, 2013, 2:16 PM UTC

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?

Too many people were trained to think in the OO style, especially class-based OO, no matter if it fits the problem or not. Any language with prototype but not classes will end up with hand-crafted classes. Any language without neither will end up with hand-crafted prototypes.