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

11–20 of 75 posts

Re: Golang Object Oriented Design

#11

Post by tiziano88 »

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 the same as you, and I suspect that in this respect Go was designed to appear familiar to programmers coming from other languages, and they decided to stick with the receiver syntax.

Re: Golang Object Oriented Design

#12

Post by Touche »

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

AddressCompare seems good to me.

Re: Golang Object Oriented Design

#13

Post by fauigerzigerk »

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

Multimethods don't have that problem.

Re: Golang Object Oriented Design

#14

Post by harrytuttle »

Touche wrote: post #12
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..

AddressCompare seems good to me.

Until you have an IDE that has to infer what it applies to.

Your global namespace would be so incredibly polluted.

Re: Golang Object Oriented Design

#15

Post by qznc »

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?

OOP is about polymorphism. Classes and inheritance are not necessary, just like encapsulation or private data. In long: http://beza1e1.tuxen.de/articles/oop.html

The question is not where the type syntactically is. The question is, if the dispatching between functions/methods happens dynamically or statically.

Re: Golang Object Oriented Design

#16

Post by lucian1900 »

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

With multimethods, that doesn't happen. You declare the compare multi (dispatch point), then you can declare as many compare methods as you want.

Re: Golang Object Oriented Design

#17

Post by 4ad »

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

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.

Re: Golang Object Oriented Design

#18

Post by qznc »

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…

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.

Re: Golang Object Oriented Design

#19

Post by qznc »

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 is not necessary. C++ provides function overloading as well.

Re: Golang Object Oriented Design

#20

Post by fauigerzigerk »

qznc wrote: post #18
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…

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