Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialagung laksana
Courses Plus Student 71 PointsBundle and NS prefix syntax
I get lost when Pasan explains about bundle and syntax using NS as prefix, if i want to learn about these two, is there any lecture video about these two ? or what I have to learn first ?
thanks in advance
2 Answers
Michael Hulet
47,913 PointsThis has a bit of background to it and it would help a lot if you knew Objective-C, but I'll try to explain it.
Some of the frameworks you use to develop iOS apps have existed for a long time (since since the 1980s), long before Swift was created. In particular, I'm gonna talk about Foundation, which is easily in the top 2 most commonly used frameworks on iOS. You can still use all of them in Swift, but like all of Apple's frameworks, Foundation is written in Objective-C. In fact, Foundation was written to act sort of as Objective-C's standard library. Objective-C didn't always have the concept of modules like Swift does now. Nowadays in Swift, if I make a library that you wanna use that has a class
/struct
/enum
/protocol
that's named the same as one of your class
es/struct
s/enum
s/protocol
s, it's easy to disambiguate, like this:
import MyFramework
let mine = MyFramework.SomeObject()
let yours = YourApp.SomeObject() // This is an entirely different class/struct/enum/protocol than the one above
In Objective-C this was/is impossible. When you imported another framework, all of its symbols were effectively pasted into your app, so if you named something the same as in a framework you're using, it'd cause a compiler error. Objective-C's solution at the time was to have every developer add a "class prefix" to their classes. Instead of naming my class SomeObject
, I'd name it MFSomeObject
, and you'd name yours YASomeObject
. That way, their names would be different, and it wouldn't cause a compiler error. A class prefix is (usually) 2 capital letters that you put at the beginning of your class name, and those 2 letters are usually your initials or your project's initials. My name is Michael Hulet, so I usually use MH
, but I'm working on an app right now called DinnerRoll, so I might use DR
in that project. Objective-C and the Foundation framework were written by a company called NeXT (which was bought by Apple in the '90s), and their popular operating system was called NeXTSTEP, so the class prefix they used in Foundation was NS
.
The developers of Swift decided that since Swift has modules, it doesn't look very good in Swift to have class prefixes in front of every symbol. They've recommended from the start to not use class prefixes, but in Swift 3, they took it so far as to want to remove the NS
prefix from all of Foundation's symbols. They decided that rewriting Foundation from scratch in Swift would be an unreasonably insane amount of work, so they made the Swift compiler understand what was going on and had it understand that when you write Notification
(or something like that), you actually want to be using the NSNotification
class. Thus, in Swift 3, you must write it like that, and it won't recognize the NSNotification
symbol anymore.
agung laksana
Courses Plus Student 71 PointsThanks Michael!