Returning Tuples
So far, we’ve taken a thorough tour of what Swift offers for object-oriented development. In a lot of languages, that would be enough. But in Swift, it’s only half the story.
Swift is great for object-oriented programming, but it also allows for more of a functional programming style. In functional programming, there’s an emphasis on passing data around, instead of maintaining state in classes and mutating it all the time.
One significant trait of functional programming is that it’s better to pass values to and from functions, rather than references. If we have an object of some class, and two parts of our code can modify its data at the same time, it can lead to confusing bugs. In functions, we generally want to pass the data itself, not a containing object. In other words, we prefer pass-by-value to pass-by-reference.
One thing that makes this difficult is the fact that functions can take many parameters, but they can typically only return one thing. Sometimes, it’s natural to want to return multiple values from a function, and in some languages the options to do so are either to define a new type solely to hold those multiple values, or to use some kind of collection.
In Swift, we have tuples, which are just simple lists of values. One way to think of it is that just as a function or method can take a list of values wrapped in a pair of parentheses, a tuple lets us return a list of values wrapped in a pair of parentheses.
Let’s give our existing IOSDevice class a computed property that returns a tuple of the screenHeight and screenWidth. Up with the other computed properties, type the following code:
| | var screenHeightAndWidth : (height: Double, width: Double) { |
| | get { |
| | return (screenHeight, screenWidth) |
| | } |
| | } |
This is a lot like our other computed properties, but the type of the variable is in parentheses, which makes it a tuple. Inside the tuple definition, we identify each member by a name (which is not required) and a type. So, this tuple has two members, named height and width. Then we just use parentheses in our return line to package these values into a tuple.
To use the tuple, just access it like any other variable. Outside the class, after creating the iPhone6 variable, pull out the values like this:
| | iPhone6.screenHeightAndWidth |
| | iPhone6.screenHeightAndWidth.height |
| | iPhone6.screenHeightAndWidth.0 |
For the first line, the evaluation pane shows all the values of the tuple, as (.0 138.1, .1 67). We can then access a value inside the tuple either by the name, like height, or its index in the tuple, like .0. Both of these evaluate to 138.1.
One place that tuples really shine is in counting over collections. In the last chapter, we said that iterating over a collection meant going either by index or by object. Tuples let us have our cake and eat it too. That’s because Swift defines an enumerate function that returns members of a collection as tuples of each member and its index. This lets us do a for-in loop where we have access to both the member and the index inside the loop.
To try it out, we’ll need a few new IOSDevice instances and a collection. Add the following at the bottom of the playground:
| | let iPhone6Plus = IOSDevice(name: "iPhone 6 Plus", |
| | screenHeight: 158.1, screenWidth: 77.8) |
| | let iPhone5s = IOSDevice (name: "iPhone 5s", |
| | screenHeight: 123.8, screenWidth: 58.6) |
| | let iPhones = [iPhone5s, iPhone6, iPhone6Plus] |
This creates an array of three IOSDevice objects. If you like, check them out in the results pane with the QuickLook or Show Result button on the line that creates the iPhones array. Now we’ll use enumerate to count over them with a tuple:
| | for (index, phone) in iPhones.enumerate() { |
| | NSLog ("(index): (phone)") |
| | } |
Inside the for loop, we now have access to the index and the phone object each time, so we can easily log them out with NSLog. In the console (View > Debug Area > Show Debug Area, or ⇧⌘Y), we can see the output that shows each:
| | ClassesPlayground[2947:1037546] 0: iPhone 5s, 123.8 x 58.6 |
| | ClassesPlayground[2947:1037546] 1: iPhone 6, 138.1 x 67.0 |
| | ClassesPlayground[2947:1037546] 2: iPhone 6 Plus, 158.1 x 77.8 |
What's an Object, Anyway?
I (Janie), like many people, learned programming in the age of Imperative Programming. Java has been around for twenty years and many people learned programming with Java. A lot of us don’t know anything except the object-oriented way of doing things. To many of us, this is what programming is.
It doesn’t have to be.
One reason I am so vocal in my defense of Swift is because this realization has completely changed my reality. I used to think there was only one way of doing things. Well, I won’t say that. There was one right way of doing things and then there was the “Dear god, what is this person thinking by having this property controlled in four different places?!” way of doing things.
Being exposed to Swift and seeing that you don’t have to put everything in a class has been a revelatory experience for me. It is forcing me to reevaluate everything I know about programming.
I never thought about what an object was before; there was no point because everything was an object. Now I am trying to get a better understanding of what an object actually is. I wrote a blog about the difference between structs and classes, and at the time I really didn’t understand why you would want to use a struct instead of a class if they essentially do the same things. I now understand that you want to try to use structs when possible because they aren’t objects. Objects come with a lot of overhead. They let you do some more powerful things like subclassing through polymorphism, but you don’t always need to do those things. Looking at how powerful the enums are that Brad Larson (my boss and mentor) uses in his code, I am fascinated by how confined my own view was when I thought everything had to be an object and exist in a class.
So, yes, I once did ask what an object is. I know most programmers worth their salt can tell you the definition of what an object is, but I don’t think many of them stop to think about why we use them and if they are the best way of doing things. Or if they bother to wonder if objects are the only way of doing things.
