[MUSIC] Hi everyone. So in this module what we'll be doing is comparing Objective-C and Swift. And seeing some things you're doing in Swift, how the same things can be done in your Objective-C. Now the point is not that in this one section you become an expert in Objective-C. But the point is, if you see Objective-C in a section of code, or if you just want to understand what the difference is, then hopefully this module will help. Now today we have Mike and Jack, who are the experts in Objective-C and Swift. I'll be chiming in as well at certain times, but they'll be explaining how we can create some of the exact same thing in Swift and Objective-C. And we'll be putting them side by side and providing a point of comparison. So Jack, do you wanna start by saying how we're going to set this up? >> Yeah, so here we're gonna set up a project in Xcode. This is because playgrounds are not available for Objective-C. So we've been using playgrounds mostly up to now. But now we have to create actual project to use Objective-C. So don't worry about this too much yet, as we'll cover this in the upcoming courses on iOS. But right now we're just going to create a project called Objective-C Swift and the language is going to be set to Swift. Okay, here. And again, don't worry too much about- >> All of these details, cuz we will be discussing these details when we start creating full apps in the next course. But right now the goal is that you become comfortable with the language of Swift. And have a bit of a point of comparison with Objective-C. >> All right, so where should we start, Mike? >> Well let's think about what we're trying to create. Maybe something to do with cities. So could we create a class to model a city and a country and store that data somehow? And compare how that would work between a Objective-C and Swift. >> Yeah, sure, so let's create, I guess to both we're gonna create city, then country objects, in both Swift and Objective-C. So let's start. >> So our city objects will have a city name and a population. And a country object will just be a bunch of cities and a name for the country. >> All right, well, again, don't worry too much about creating these new files in the project right now. So I'm just gonna create city.swift, and this is a .swift file, which means it's in Swift. And then also a city file an Objective-C. >> Don't forget to call it UT. >> Very good point, and do you wanna say why it should be- >> Well we don't want to have multiple types of classes with the same name. And also, in Objective-C, it doesn't have any kind of name spacing built in, so you actually have to add letters at the beginning. This is a traditional Objective-C thing to do, is add these letters at the beginning to identify which classes belong to you. Just in case there's a class somewhere in coco that's called city. You don't wanna overwrite that class. So, we're gonna add UT. Could be anything, could be your initials, could be your company name, could be anything like that. But the convention is to capitalize those two letters there. >> Yeah, in Swift we don't have to do that because even if the system has the city class we won't be conflicting with that class, basically. >> And incidentally, that's why it's called NSObject instead of just object as you can see on the screen there. Traditionally that's from next step, where Objective-C started. >> Yeah, very interesting, I guess- >> It's a carryover. [LAUGH] >> From classes before in Swift, we didn't really need to inherit from NSObject, in Swift. >> The Xcode added that on its own. But we can just even delete that, it won't complain. >> We're gonna remove that. >> But it's required for Objective-C. >> Yes. So, let's talk about what we're looking at here. So after we created the class as you notice, Swift created one file called city.swift, and this is all of it. Where as in Objective-C, created UTCity.h, what you are seeing here, and UTCity.n. So it's a lot more like C++, I guess. >> Yeah, if you want to have methods available to other parts of your program, or properties, or any other sort of parts of your class, to make them public you have to put them in the .h file. So that your other source code files know about them. Swift, by default, everything is public. You don't have to copy over any function or method signatures into another file. It just all goes in the same single file. So, the .h file doesn't include any implementation or actual code. It just includes definitions of properties and method signatures or basically lists of parameters for methods and their names. Everything goes into the .n file that's actually code. >> Let's just look at the difference in syntax here. Swift, you're defining a class, so you say class, and that's very straightforward [LAUGH]. >> Yeah. >> That's very nice. For Objective-C, we have quite a bit going on. We have a @interface, which like Mike just said, it defines the interface, sort of the public interface to your class of city. And then, but that's not all. Then you have to go to the .n file, and you have the implementation block. Which would then implement whatever functions and methods you defined in the interface.
