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

Struct composition with Go

dave.cheney.net

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Struct composition with Go

#11

Post by pcwalton »

jaekwon wrote: post #8
justinsb wrote: post #7

Earlier quoted context omitted.

It looks more like inheritance: the methods on net.Conn & io.Writer are automatically exposed. Are you saying that it is composition because you are "inheriting" from interfaces, which isn't traditional inheritance? Or if not, can you explain why you think of this as composition and not inheritance? Edit: On further thought, this looks to me like composition with automatic delegation (a huge productivity benefit of i…

The inner structs (of which the outer writer struct is composed) cannot access any of the functionality or fields outside of itself. Each inner struct is completely encapsulated, so you can't override an inner struct method and expect the inner struct's behavior to change. The accessibility of inner struct methods from the outer struct is a syntactic convenience. Java: https://gist.github.com/jaekwon/8025b9f3a482b321…

There are also no virtual methods with struct composition. If B embeds A, "upcasting" an instance of B to A will not allow you to call any methods on B.

Re: Struct composition with Go

#12

Post by [deleted] »

gohrt wrote: post #10
zenocon wrote: post #6

This is cool, but I find this snippet a tad bizarre: client, server := net.Pipe() var buf bytes.Buffer client = &recordingConn { Conn: client, Writer: io.MultiWriter(client, &buf), } While it seemingly works, it seems confusing to assign client to an internal field of a new struct, and then overwriting that same client variable with the newly created struct...not to mention passing it into MultiWriter. Anyway, I like…

What is the benefit of re-using the 'client' identifier? There's no closure capturing the identifier. Compare: client, server := net.Pipe() var buf bytes.Buffer client = &recordingConn { Conn: client, Writer: io.MultiWriter(client, &buf), } vs tempClient, server := net.Pipe() var buf bytes.Buffer client = &recordingConn { Conn: tempClient, Writer: io.MultiWriter(tempClient, &buf), } The latter is less confusing to me…

[deleted]

Re: Struct composition with Go

#13

Post by aikah »

justinsb wrote: post #7
davecheney wrote: post #5

Earlier quoted context omitted.

Nope, this is composition, not inheritance.

It looks more like inheritance: the methods on net.Conn & io.Writer are automatically exposed. Are you saying that it is composition because you are "inheriting" from interfaces, which isn't traditional inheritance? Or if not, can you explain why you think of this as composition and not inheritance? Edit: On further thought, this looks to me like composition with automatic delegation (a huge productivity benefit of i…

This is not inheritance, careful about what you say here since it is totally misleading. while embedding structs is useful in a lot of cases, it might yield unexpected results if you expect embedding to work "more like inheritance".

ex

    type A struct{}
  
    func (a *A)GetSelf()*A{return a}

    type B struct{ A }

    b:=&B{A{}}
b.GetSelf() returns type A , not type B

It gets even more confusing when you start embedding interfaces in structs.

Re: Struct composition with Go

#16

Post by [deleted] »

gohrt wrote: post #10
zenocon wrote: post #6

This is cool, but I find this snippet a tad bizarre: client, server := net.Pipe() var buf bytes.Buffer client = &recordingConn { Conn: client, Writer: io.MultiWriter(client, &buf), } While it seemingly works, it seems confusing to assign client to an internal field of a new struct, and then overwriting that same client variable with the newly created struct...not to mention passing it into MultiWriter. Anyway, I like…

What is the benefit of re-using the 'client' identifier? There's no closure capturing the identifier. Compare: client, server := net.Pipe() var buf bytes.Buffer client = &recordingConn { Conn: client, Writer: io.MultiWriter(client, &buf), } vs tempClient, server := net.Pipe() var buf bytes.Buffer client = &recordingConn { Conn: tempClient, Writer: io.MultiWriter(tempClient, &buf), } The latter is less confusing to me…

[deleted]

Re: Struct composition with Go

#18

Post by jerf »

Rexxar wrote: post #17
davecheney wrote: post #5

Earlier quoted context omitted.

Nope, this is composition, not inheritance.

I would say that it's inheritance without polymorphisms or a sort of mixin.

It isn't inheritance at all. Read the other replies. When an embedded struct has a method called on it, it is completely oblivious to what it is embedded in, no different than a direct call. It does not get any sort of reference to what would be a the superclass if there was any inheritance going on.

Re: Struct composition with Go

#19

Post by NateDad »

Rexxar wrote: post #17
davecheney wrote: post #5

Earlier quoted context omitted.

Nope, this is composition, not inheritance.

I would say that it's inheritance without polymorphisms or a sort of mixin.

As jerf said - the embedded struct, while exposed to users of the external struct, still has no access to anything in the external struct. You can't override the methods it calls, etc. All the methods it calls will always be its own methods, never one from the external struct.

Inheritance implies is-a, and implies that you can modify some of the internal workings of the class you're inheriting from.

Embedding is strictly has-a. It's really no different than having a member variable in any other language... there's just some syntactic sugar to make it a little nicer to access the member's methods and fields (and the methods "count" for fulfilling interfaces).

Re: Struct composition with Go

#20

Post by TheDong »

shoo wrote: post #2

Since the purpose of this is apparently to provide a fake structure to test against - would another viable approach have been to implement a trivial `Close` function that doesn't do anything? (context: i am no gopher) (edit/tangent: i wonder how method calls from inside method calls are resolved when the names are ambiguous?)

I suspect your tangent is because you don't fully understand how composition works. Basically, it's weaker than you think I believe.

I tried to write an example that demonstrates why I don't think the ambiguity you're referring to is possible.

https://play.golang.org/p/TyMJbOjDdZ

Post reply on HN