Is there any difference between struct embedding and defining a field with the struct you want to embed?

So I'm looking at this article on Structure Embedding in GoLang.
When reading, I came upon this: "Note that the access co.b is a syntactic convenience; we can also do it more explicitly with co.Base.b.".

So if that's just a "syntactic convenience", is structure embedding equal to just adding a field?
E.g.

type A struct {
  Msg string;
}
func (this *A) Print() {
  fmt.Println("A: "+this.Msg);
}

type B struct {
  A;
}
func (this *B) Print() {
  fmt.Println("B: "+this.Msg);
}

==

type A struct {
  Msg string;
}
func (this *A) Print() {
  fmt.Println("A: "+this.Msg);
}

type B struct {
  A A;
}
func (this *B) Print() {
  fmt.Println("B: "+this.A.Msg);
}

Putting:

package main;

import "fmt";



type A struct {
  Msg string;
}
func (this *A) Print() {
  fmt.Println("A: "+this.Msg);
}

type B struct {
  A;
}
func (this *B) Print() {
  fmt.Println("B: "+this.Msg);
}

func main() {
  var test B = B{};
  test.Msg = "Hello!";

  test.A.Print();
  test.Print();
}

into SoloLearn's Go playground that seems to be the case.


So is there any difference, or am I right about them being the exact same thing?

Comments

[moose]

Data Classes, Data Access Objects, structs. Its a better way to build "data objects" in golang that don't have that functional requirement and just are there to store contextual data.

What you built is fine and unless you have coding conventions it really doesn't make a huge difference unless you start a legit build. Then it would be a prudent move to refactor it to a more coherent and delineated structure.

The only comment I have is the use of the "this", I think golang guides say to refrain from the use of it. And its a legit point as "this" is generally a keyword or a contextual object. Its better to name your variables something distinct and descriptive about them. i.e.-> instead of "this" use "a_Struct" as it is easy to derive its origin or use should the files become decoupled or moved later.

[Calin Baenen]

I know, but shouldn't this be okay as method names, like in a language like Java, or JS (where it's already defines as a keyword)?
Is it okay to use this if I keep my methods grouped in the same general area (file, and location) as the method's host-type?

[moose]

There isn't anything technically wrong with it, and you can certainly do that if that is the most prudent naming convention for you. You'd likely run into null pointer exception in java and scoping issues in js it though. You'd also probably catch some heat in any code review should you choose that kind of convention.

The problem with using a lot of objects with vague naming conventions is readability and maintainability. If you ever had to come back after a while and add a feature its dollars to donuts you won't be 100% on what is exactly executing and why in the file and you would be more prone to make errors where there once was none. And thats an everyone thing, we all do it/did it before and set ourselves up for failure later on.

So with that in mind: once you start progressing to more advanced topics and when what you write starts becoming more complex than the example I saw earlier you will run into spaghetti moments no doubt. Even Rob Pike takes notes. If you added any kind of complex logic to your file and tried running it in multiple thread, you would have vague errors everywhere pointing to "this" and it would be a nightmare.

No private marking for class inits, no kind of scoping thats obvious, no real type hints without reflection tools making things harder to maintain in the future because you'll forget stuff (we all do) and coming back to any kind of complex code with no set up documents of meaningful purpose.

Being young like you are, you'd be ahead of the pack starting to enforce good habits surround your development chops. If you still have reservations about it: I recommend in earnest, you find a medium size Opensource Project, clone it and just attempt to reverse engineer it. It would be a good exercise for you to experience to see what an actual onboarding is like.