<p>Hi, I'm an aspiring gopher learner trying to wrap my head around interfaces and what implements what. Here's some code that I wrote to test things out: <a href="https://play.golang.org/p/B0Eew8SvKZL">code</a> And here's my question:</p>
<p>I define two structs. One is "person". And one is "chemist" which contains "human". (presuming that all chemists are persons!) Then I create a "human" interface that only has one function "Greeting()" which is declared separately. I also create a "scientist" interface that contains only one function "sciGreeting()". And then I declare that "sciGreeting()" right after.</p>
<p>Later, in the main() I initialize the person variable and assign it to "u" (to be human), following by creating a "v" variable and initializing it with the "u" and another string (to be a chemist). This is where it gets peculiar.</p>
<p>I understand that </p>
<pre><code>Greeting()
</code></pre>
<p>implements human because the function name is the only part of the </p>
<pre><code>human
</code></pre>
<p>interface and has a (i *person) as a receiver. And so</p>
<pre><code>person
</code></pre>
<p>or </p>
<pre><code>u
</code></pre>
<p>has access to the greeting. </p>
<p>What I can't understand is why </p>
<pre><code>v
</code></pre>
<p>has access to both </p>
<pre><code>sciGreeting()
</code></pre>
<p>AND </p>
<pre><code>Greeting()
</code></pre>
<p>Meanwhile, "u" doesn't!</p>
<p>I mean, the code is working as intended. A human scientist has access to both human and scientist greetings. But I just can't see why!!! There's no point of intersection between the two interfaces or greeting functions. </p>
<p>I can only imagine that it's because "person" struct implements "human" by having Greeting() the pointer to the "person" struct as its receiver? So, when I create another variable, "v", that contains that struct, "v" (a chemist struct) also inherits the access to Greeting() from "u", the "person" struct (human interface)? So, the "chemist" struct then implements the "scientist" interface through the "sciGreeting()" function that has the "*chemist" receiver in it? </p>
<p>Am I right? </p>
<hr/>**评论：**<br/><br/>GopherFromHell: <pre><p>The method Greeting is declared on a pointer receiver and in your chemist struct is declaring a value.</p>
<p>take a look <a href="https://play.golang.org/p/0NrhQ_Bn0ed" rel="nofollow">at this example</a>. The documentation of the language on <a href="https://golang.org/ref/spec#Struct_types" rel="nofollow">structs</a> might also be useful to understand embedded fields (and how they interact with interfaces)</p></pre>xiegeo: <pre><p><a href="https://play.golang.org/p/04Lud8ExLVW" rel="nofollow">https://play.golang.org/p/04Lud8ExLVW</a></p>
<p>See that last line that I added. It does not compile so a person is not a human.</p>
<p>You can use this way to test if a struct correctly implements an interface. This is what interface is for, to make sure certain rules are followed.</p></pre>govision: <pre><p>Yeah it's because u only has one of the methods and is embedded. It isn't I guess you can say top level. You are expecting the compiler to kinda do what js does which is run 12 times and make the best guess inside a nested statement. Almost like js eval(). It's evil for a reason lol but easily misunderstood.</p>
<p><a href="https://play.golang.org/p/IA09xBX7dYF" rel="nofollow">https://play.golang.org/p/IA09xBX7dYF</a></p></pre>ODAwake: <pre><p>Ah, that is fantastic, thank you!</p>
<p>So, I see that this way structs can "inherit" the properties of structs inside them and have the access to all the functions that are associated with them. I'm a fairly new programmer, so I am not really familiar how inheritances work in other languages. This seems pretty logical.</p>
<p>And this makes sense in my code now too. I had </p>
<pre><code>person
</code></pre>
<p>embedded in </p>
<pre><code>chemist
</code></pre>
<p>So chemist was the higher level. And when I created a separate interface with a caller for chemist, it was available only to the top level struct, and not the bottom level, original "human" struct. </p>
<p>Cool beans, man! Thank you!</p></pre>govision: <pre><p>Yeah I got a few links on interfaces here.
<a href="https://docs.google.com/document/d/1Zb9GCWPKeEJ4Dyn2TkT-O3wJ8AFc-IMxZzTugNCjr-8/edit?usp=drivesdk" rel="nofollow">https://docs.google.com/document/d/1Zb9GCWPKeEJ4Dyn2TkT-O3wJ8AFc-IMxZzTugNCjr-8/edit?usp=drivesdk</a></p>
<p>But to be honest, I wouldn't over use them cause they really are specialized glue for a "reusable" package. It's not really meant to just carry over methods. </p>
<p>I'm kinda trying to write an article on types....ish but it's really dry cause I didn't add context but the point was an appreciation of the design of the types not so much high level stuff. But it helps you understand packages instead of just using them.</p>
<p><a href="https://medium.com/@d35da8f0b148/2ba61290a5cf?sk=" rel="nofollow">https://medium.com/@d35da8f0b148/2ba61290a5cf?sk=</a></p>
<p>And</p>
<p><a href="https://medium.com/@d35da8f0b148/30fa200bef8f?sk=" rel="nofollow">https://medium.com/@d35da8f0b148/30fa200bef8f?sk=</a></p>
<p>And thank you for the gold!!!!</p></pre>jerf: <pre><p>Can you put some code capturing your question clearly up on <a href="https://play.golang.org/" rel="nofollow">the Go playground</a>? It would help answer this.</p></pre>
