[MUSIC] Okay, so now that we have the basic infrastructures set up for shell set up, let's see what we can do in Swift and Objective-C, and how we compare the two of these. >> So, we've done a quiet a few things in Swift already but we're just going to go through all the basics again to see how they are different. >> Yeah, I think that would be useful. I guess the first thing in our city is the name, and in swift we've all done this before it needs a constant and it's a String, and we also have a population of Int, that's all we're gonna store in this city. It's gonna complain about it not having initializers, which you've seen before. And we're gonna now waive that back, just now. How do we do this in Objective-C would use, like we would have to actually create a property, right. So, the syntax, I'll write it out first and we can discuss it. [SOUND] >> So, right off the bat we see the properties. One is strong one is, what is the term exactly? >> So, that is the same that you previously learned is Swift, that there is strong and weak pointers The difference. So, Objective-C, it's more explicit. You have like in our name is really a value, which doesn't need to be classified in this case. But, in Objective-C the string is not of any type, as you can see to the star which means pointer. So, it's actually a pointer to a string, which means that it needs to the memory arc is the no. [LAUGH] >> And this is a lot of, like, with Objective-C you see there is a lot of syntax and a lot of stuff you have to write compared to Swift. And maybe we should just go into one, like >> [COUGH] So, you can go into a bit of detail because, I think perhaps, for some of the audience, maybe. This is not as important, but for some, that might be of interest. So perhaps, we can explore this to a little bit of detail because most of your audience are looking at this. They're saying, okay. So, here you're set. You essentially are defining a constant of name and population. That's clear. >> Yes. >> But, here you have a strong parameter, nonatomic. What do these things mean? So, I think perhaps we could look into that. >> So, those are good points. But, let's start, I think a good starting thing before we get into these is just NS string versus string. And I mean here we have NS string with a star which is a pointer type versus string, and Mike do you wanna? >> Yeah, so all Objective-C objects are, I guess in Swift, you would call them reference types. So, when you have a property that stores a string, it really just stores a reference to that string, and the reason you have that star there is that, really, we're actually compatible with c, and if you're familiar with c, you know that. You could have a variable like an integer that's just stored in a variable. Or you can have reference to some kind of dynamic memory so you have a pointer to that and that gets kind of complicated, but the idea is that. That name doesn't store the string, it just stores a reference to an NS String object. So, the difference. That's why the NS integer doesn't have a star because it is, the population actually stores the population value, which more like Swift is doing as well where it has a population. Of there. So, that's why you have the strong, because somebody has to own that string. Otherwise it will become de-allocated. It will disappear. So, we want this city to make sure it always has a strong reference to it's name, so it's always known as at least one of the owners of this name. The population is just a value. When it gets passed around, when you assign a population, it copies that. Value to the population variable. So, you can just have assign as the storage class there. These are things that are important, because Objective-C retains compatibility with c and it has these distinctions, whereas Swift, it's more implicit. Everything is a reference type or a value type like a String. For example, or an int, or value types, and it's more implicit in how they're stored. They're strong by default, for example. A String is copied every time you assign it because it's a value type, whereas in Objective-C, a String is, you're just copying a reference to a String, so it's not necessarily copied if you assign it. So, that's why you have these more explicit controls over properties. >> Yeah, so the key difference is definitely the reference type versus value type, where, as in Swift here, we do not have any reference types currently, but in Objective-C, a String is not a value type. >> Yeah, it forces, really, you have to think more about how the memory is managed in Objective-C, for sure. >> Mm-hm. All right. So, should we solve this error here? >> Yeah. So, what is this error's name? It has not initializers. So yes, we've seen this before. We can define initializer for city, and it'll take a name and a population. And all it's gonna do is assign initializer variables, our property. Okay? And now we're gonna do the same thing in Objective-C which requires us to go into implementation and write a whole lot of stuff, which apple helps us. With this. >> Yeah, we can use that. >> Yeah, so when you type init on Objective-C, X code will expand. And we looked at this when we were looking at X code. It's sort of a snippet that it puts in for you. And when you hit enter, it gives you all of the code you need. And here we are. >> So, this is like a minimal type of initializer foreign object in Objective-C, this one currently doesn't take any parameters but Jack is gonna add some parameters for us there. >> Yeah, so we want to take the same exact parameters which is the name. >> Notice the minimal initializer still has a lot of stuff in it [LAUGH] it's not quite as simple as a minimal Swift initializer. All right. And this line is already so long it goes off the side of the screen and wraps around. But, here the code is actually, exactly the same. All right. >> Yeah, so the important stuff is the same, right? You're assigning the name in the population. But in Swift, you notice that's it, right? Objective-C, it has this thing where it calls a method on the super class. I mean, you can guess that it's calling it on the super class, right I mean it's pretty straight forward. You have to do that explicitly in Objective-C. You don't have to do that in Swift. As you covered already how that works. And then what happens is the super class could return null, it could fail in its initialization. And then you have to check if self is null before you can actually assign any variables to it, assign any values to the properties. Which is in Swift, because self is a not an optional type. It's guaranteed not to be null ever. In Objective-C this is just one of your first instances you'll ever see of every time you have a value, if you don't know if it's going to null, you have to check. Otherwise, unusual or unexpected things could happen. In Swift if it's, it either won't let you compile the code or it would just crash. >> And you see later when you we use these functions. They're also called a bit differently. I guess another difference I want to point out is in Objective-C. This is Method, the same exact syntax as any other method that could be on the class, where as in Swift, we have this special sort of syntax for initializers, as we've seen before with init. And if you were to define methods, you would use the funk keyword. But, Objective-C as you also see, very soon, wen we define a method it looks exactly the same as initializer. So, they're not special in any way, it's just that the system calls them specially as initializers. >> Right, and don't forget to copy that method definition over to the H files so that it's. Available to our code. [LAUGH] >> That's a very good point because we want, someone else is gonna be calling this. We're not gonna be calling this, the city won't be calling it itself. So, that means we have to also have this function, to the H files so that the rest of your program can see it. >> Yeah.
