category]. Person will be in org.wiley.kotlin.person and User will be in org.wiley.kotlin.user.
NOTE You don't always have to have the last part of the package name (like person) match a class in that package (like Person). You might have an org.wiley.kotlin.sport package that has various sports-related classes like Football, Baseball, Hockey, and Volleyball, but not have an actual Sport class. It really depends on your own preferences and style.
Put Person in a Package
With a package decided, you need to actually create this structure. Again, this is where an IDE can really make things simpler. If you're using IntelliJ, right-click your src/ folder and choose New and then Package. Type in the package name ( org.kotlin.wiley.person if you're following along, or use your own name), and you'll see a small package indicator created as part of your src/ tree.
WARNING Each IDE handles this a bit differently, but the similarities are far greater than the differences. You can always just play around with the IDE to look for a New Package option (that's what I did when I was first learning Kotlin in IntelliJ), or check your IDE's documentation.
If you're using the command line exclusively, it's a bit more of a pain. You'll need to create a directory structure to match your package structure, so you'd need an org/ directory, and then wiley/, then kotlin/, then person/, and then put your Person class there. You'll also need to work with the kotlinc compiler a bit more.
You can find this documentation easily online, so to keep things moving, most of this book will assume you're either using an IDE or comfortable looking up how to compile files in packages on your own.
Now comes the “thank goodness for an IDE” part: just click your Person class in the left pane and drag it into the new package indicator. You'll get a dialog box that looks like Figure 2.2.
FIGURE 2.2 Moving a class to a new package is basically a refactoring, which your IDE can handle.
This dialog will ensure that yes, you really do want to move the class into the indicated package. You can leave all these defaults, as IntelliJ is happy to do this work for you. When you're ready, click the Refactor button.
Now, your navigation pane (on the left in the IDE) should show Person under the new org.wiley.kotlin.person package, as shown in Figure 2.3.
Before you think that too much magic has gone on, take a close look at the first line of your Person class, which is new:
package org.wiley.kotlin.person
That line tells Kotlin that the class belongs to the org.kotlin.wiley.person package. The compiled class then actually is org.kotlin.wiley.person.Person, not just Person.
This is going to cause your main function to break, because that function doesn't know anything about org.kotlin.wiley.person.Person; and now there's no Person class.
FIGURE 2.3 Person is now nested under its containing package.
WARNING This is a great example of a very small detail having a very big effect on your code. A class without a package, and a class within a package, are not the same at all—even if they are named the same. You could theoretically have multiple classes named the same in multiple packages, and each is distinct from the other. Hopefully you're already thinking this is a bad idea; but it is possible.
The point is important, though: naming matters.
Normally, you'd need to make a change here, but again, the IDE has done some nice work for you. Check out your file with main in it ( PersonApp if you've followed along); it also has a new line at the top:
import org.wiley.kotlin.person.Person
This line tells Kotlin to import, or make available, the org.kotlin.wiley.person.Person class without needing to refer to it by its complete name. It essentially says “import that long name and allow it to be referenced by just the class name: Person.”
NOTE You could also leave out that top line of the main file and just refer to the class by its entire name every time you use it. So you'd create a new instance like this:
val brian = org.wiley.kotlin.person.Person("Brian", "Truesby")
You'd have to do this for every reference to
Person
, though. Developers don't typically like this, as it's a lot of extra typing, so using
import
is a lot more common.
With all these changes in place, you can recompile and run your program again. Things should work beautifully (although that last name is still wrong!).
Classes: The Ultimate Type in Kotlin
Before getting further into Kotlin types—something this chapter is going to spend the rest of its time on—it's worth saying that classes are really the ultimate type in Kotlin. A class provides you a way to collect data and work with that data in a specific manner, and to model things in the world: numbers, sentences, objects like cars, people, even abstract ideas like a radio wave or a decision.
Classes also give you a pointer into something that's quite important in Kotlin: type safety. Type safety refers to the degree to which a programming language keeps you from making mistakes related to assigning one type (like a number) to a variable that should only hold letters. There's nothing as frustrating as treating a variable like it's all letters, and things in your program break because it turns out that that variable actually contains an instance of Person (or Car, or User, or something else that doesn't at all act like letters).
And that's where classes and objects are so key to type safety. Your Person is now strongly typed; you can't create an integer and shove a string into it. More specifically, you can't create a Car and shove it into a Person. You're going to see a lot more about this as the chapter goes on. For now, though, just think of objects as a really powerful way to be sure a variable (whether by val or by var) has exactly
