Golang Object Oriented Design • Hacker News Board

Re: Golang Object Oriented Design

#21

Post by davedx » Mon, Sep 16, 2013, 12:54 PM UTC

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…

I see pretty much the same problem with JavaScript. It's everywhere -- framework developers are busily implementing polymorphism, inheritence etc. all over the place. Yet I can't recall ever choosing to use "inheritance" instead of composition in my JavaScript projects.

Re: Golang Object Oriented Design

#22

Post by qznc » Mon, Sep 16, 2013, 12:54 PM UTC

laumars wrote: post #9

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?

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

Re: Golang Object Oriented Design

#23

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

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.

Re: Golang Object Oriented Design

#24

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

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…

> Go doesn't have an implicit "this" pointer.

You want to say Go doesn't have an explicit "this" pointer.

Re: Golang Object Oriented Design

#25

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

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.

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.

Re: Golang Object Oriented Design

#26

Post by pjmlp » Mon, Sep 16, 2013, 1:02 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?

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.

Re: Golang Object Oriented Design

#27

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

masklinn wrote: post #8

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? Like Self or javascript?

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

Re: Golang Object Oriented Design

#28

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

adamlett wrote: post #27

masklinn wrote: post #8

Earlier quoted context omitted.

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

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.

Re: Golang Object Oriented Design

#29

Post by [deleted] » Mon, Sep 16, 2013, 1:09 PM UTC

_pmf_ wrote: post #24

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…

> Go doesn't have an implicit "this" pointer. You want to say Go doesn't have an explicit "this" pointer.

[deleted]

Re: Golang Object Oriented Design

#30

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

_pmf_ wrote: post #24

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…

> Go doesn't have an implicit "this" pointer. You want to say Go doesn't have an explicit "this" pointer.

No, what I mean is that you have to refer to the receiver explicitly even from within methods invoked on that same receiver, contrary to Java or C++ where 'this' is implicitly assumed when you refer to other members of the receiver.