In this lesson we're going to be discussing packages when it comes to Go, specifically how we import packages and how we can use them within our own code.

Currently we've been interfacing with packages in two main ways. The first is that we've been defining our own package inside of our code, specifically package main. If we take a look at the Go Dev documentation, you can see that every Go program is made up of packages, and programs start running in the package main, which is what we've defined in all of the applications that we've built and ran so far.

This program is using packages with the import paths of fmt and math/rand. Again this is what we saw when we were importing the fmt package, which is a package provided by the Go standard library. As we saw before, fmt which stands for format, or is shorthand for format, and provides a number of different functions that we can actually use.

Throughout the first part of this course we're mostly going to be building inside of the main package, and there's a good reason to do so. This is because all of the types, functions, methods, etc. that we define inside of that package will be available to that package. This is because code in Go is package scoped, meaning if we go ahead and create a new file inside of this code, let's say we actually go ahead and create fighter.go, and whilst we're here, if I go ahead and split the screen and open up the main package, if I go ahead and remove my Goku and my type Fighter struct, and just place this in the main package, or place this in the fighter.go file, which is still inside of the main package, I still have access to these variables. For instance, I can go ahead and print out Goku.Name and I can print out Goku.Powerlevel. Let's go ahead and get rid of this so you can see this clearly. And if I go ahead and run this code using the following command, you can see we're able to print out Goku's name and his power level. Even though neither the type Fighter struct nor var goku are defined in the same file, because they're defined in the same package, then we have access to them.

Therefore, through the first part of this course, just to simplify things, we'll be taking the same approach. However, if we were working on a larger codebase, then we may be more inclined to actually structure our code in a specific way. We actually have a couple of lessons where we look at how to structure a CLI application when it comes to Go. However, let's just quickly talk about how we could create a new package in order to store all of our fighter code, rather than having it inside of the main package, which is used for the application's startup.

In order to do so, we first need to turn our projects into a Go module or provide support for Go modules. This is done using the go mod init command, which we talk more about in the first lesson on the course. But in this case, I'm just going to go ahead and quickly speed through it. We need to give our module or our Go module a package name or a module name. I'm going to go ahead and call this dreamsofcode.io/dragonball for the moment. Don't worry too much about what this is. Just remember that this is the module name in this case. As you can see, it creates a go.mod file and we'll talk more about that in the next lesson.

In any case, now that I have used the go mod init command and we have a go.mod inside of this directory, we now have the ability to support our own packages. In order to create a new package, we first need to create a new directory, which is going to be the name of the package that we're going to define. In this case, we can go ahead and create it as fighter and I'm going to take the fighter.go file and paste it into this new directory and open it up. In here, we can go ahead and change the package name from main as it's no longer the main package and we'll change it to be package fighter instead.

Now, if I head back on over to my main package, you can see that the editor is throwing some errors. We no longer have the goku variable available because it's no longer in the same package. Therefore, in order to access it, we need to import this new package, which when it's our code, which is similar to say importing a package from the standard library. But when it's our own code, we can use the module name that we defined. So in this case is dreamsofcode.io, then defining the name of our current project, which is /dragonball, finally passing in the package name that we want to import. In this case, it's fighter. Now we're importing the fighter module found inside of our code at the fighter directory, and we can go ahead and reference the package at fighter and we can reference the Goku package variable inside. And we can do the same thing for here as well.

Now, as you can see, my code is working as it did before. The only difference is we had to import the fighter package and we had to go ahead and prefix the actual package name when we were referencing Goku because Goku in this case is a package variable. So it's defined on the package scope within the fighter package. So why would you want to do this? Well, for the most part, there's no real difference in what we were currently doing than what we were doing before. Just our code is living in a different directory. However, the key reason to use a package is that we can now constrain the visibility of types, fields, variables, functions, etc. Everything that we're defining inside of this package, we can control the visibility of.

For example, let's say we have our Goku fighter, which we are exporting due to the fact that we're setting an uppercase character. This means that other packages that import this package will have access to Goku, as well as also having access to the Fighter struct and having access to the Fighter.Name and Fighter.Powerlevel. However, if I went and actually change Goku to be lowercase goku, and if I try to run the code, you can see we now get an error: undefined fighter.Goku. Well, of course, this is because we've changed Goku's name. So we need to go ahead and reference it with his lowercase name. However, when I do so, you can see I'm still getting undefined, even if I try to run this code. This is due to how Go manages visibility or package level visibility when it comes to its code.

Basically, any name, type, method, function, etc. that begins with an uppercase letter, such as the capital G, will be visible outside of the package, or exported is the correct term, whereas anything with a lowercase letter will not be exported. To show this in more action, if we go ahead and set Goku back to being a fighter that is visible, but this time if we go ahead and change the Powerlevel field of the type Fighter struct to be lowercase p powerlevel, and we've got to go ahead and make sure we set that here as well, now if we go back to the main code and we change Goku to be uppercase G again, you can see we can access the name. And if I go ahead and just do the dot syntax, the name field is visible. However, this time, if we change Goku again, this time now the power level field isn't accessible. This is because it has a lowercase name, so anything that imports the package cannot see it.

Whilst this may feel restrictive, this is actually very good for controlling certain behaviour of our code. For instance, now our Goku fighter, if somebody imports this package, they can actually change Goku's name, but they can't change Goku's power level. This means that we can constrain the amount of mutation that goes on inside other areas of our code, and we can prevent people from being able to change values they aren't able to have access to. This is a very powerful concept when it comes to software development, as it allows you to export only a public interface, so consumers of your package what they are able to do, whilst at the same time it allows you to constrain the internal workings so that nobody can accidentally break them or call functions in a wrong way.

For instance, right now if we go ahead and look at the main.go function, we could go ahead and actually change Goku's name. Let's go ahead and change Goku's name to be Kakarot, and even though that's correct, he might not appreciate his name being changed for him. Now you can see we're printing out Kakarot. I'm actually printing it twice. Therefore, if we want to prevent this from happening, we would set the name field of the fighter to be lowercase, and it would prevent us from being able to overwrite the value, mainly because we don't have access to it.

But then how do we actually read the properties of Goku? It's all well and good having these private variables, but they're pretty useless if we can't access them. Well, there are a couple of ways. The first is you can still access them inside of this package. So we could return what's known as a getter function or an accessor function. So we could go ahead and say func GetName and we pass in a Fighter to this function and it will return a string. Then inside of this function we can return f.name. Now we can head back to our main function and get rid of the assignment because we can't assign it, but we can call the fighter.GetName passing in fighter.Goku.

Now if I go ahead and run this, you can see we're able to access Goku, but we're not able to mutate his value. This comes in handy when you think about some of the functions that you may want to apply. For example, when it actually came to the show Dragon Ball Z, whilst the power level does exist on the fighters, they were never able to actually know what the power level was until the Saiyans came in with their scanners. So for instance, we could say that a certain number of players have the ability to scan if they have a scanner item. Then you could pass in the fighter and it will return their power level back to whoever tries to scan them. In this case, you could just go ahead and return f.powerlevel.

Additionally, if you didn't want to expose the power level, you could just go ahead and say here's a function called func Fight and it takes two fighters: fighter1, which will go ahead and just set to be fighter, and fighter2, which was set to be fighter, and it will return the fighter who wins, let's say. So we can go ahead and do return f1 or if f1.powerlevel is greater than f2.powerlevel, we will return f1 else we'll return f2. We'll put the return keyword here. Now, obviously, if they're equal, then we shouldn't return any. We could change this to be a pointer, but for the moment, let's leave this as is.

Let's go ahead and create a new fighter called Piccolo, and we'll set fighter name. Actually, let's go ahead and set Vegeta because Vegeta is more powerful. name: Vegeta, and you could say powerlevel in this case was 30,000. Now, if we go ahead and head back to our main.go function, and we go ahead and do fighter.Fight, and we'll pass in fighter.Vegeta, fighter.Goku, let's say, and we'll just capture the return value of this in a variable called winner. Then we can go ahead and do format.Println, or we can do fighter.GetName, and we'll pass in the fighter of the winner. We'll do fighter.GetName, we'll pass in the winners. Now we can see who wins between the two. Let's say if we do the go run command, you can see Vegeta wins.

Of course, we could go ahead and then add in the same function we had before, which was Kaokan, and it takes in a fighter, and we'll set the power level. So we could do int in this case, and we have to make sure it's a pointer to a fighter, and then we could do f.powerlevel = f.powerlevel * 5, let's say. We don't want to return an integer, we'll just return that. Actually, we could go ahead and return a copy of this fighter, so we're not mutating the original value, let's say, and we'll just return f. Now we can go ahead and call this value, so we could go and do say poweredUpGoku := fighter.Kaokan, and we'll pass in fighter.Goku.

Now we could go ahead and see if powered up Goku beats Vegeta, which he does.

As you can see, by making use of packages, it allows us to easily constrain what is exported from our implementation, which can be very powerful when it comes to building larger projects, or if you're building out a library that you want other people to consume. As I mentioned, however, we're not going to be doing much of this throughout the first part of the course. Instead, we're going to define all of our functions and types as being exported with a capital letter. This is just to make it a little bit simpler later on when we start to move towards structuring our code across multiple packages, but this is just to keep things simple for the meantime.

In any case, that takes a brief overview of packages and how we can make use of them within our code and what it looks like when you're importing a package from the standard library. Remember, if you take a look at all of these functions, they're all uppercase, even though they do have lowercase names and methods inside in order to prevent us from being able to access some of the inner workings.

In any case, that covers the basics of the Go 101 track of this course. If there's anything else you want to learn more about, then please do message me on either Discord, or you can just drop me an email as well, and I'll do some dedicated lessons on the topic. Additionally, I am hoping to do an actual Go 101 course for free at some point, so please let me know if there's anything else you want to find out.

Otherwise, feel free to then move on to the next module, where we're going to start building our first command line application from scratch, which is going to be a simple utility in order to count the number of words inside of a text.