Sorry, but I have been waiting for months to make this pun.  So today, we are going to talk about Operator overloading in Swift.  This tool is very useful, but quite dangerous as well.  The “With great power comes great responsibility,” quote is very appropriate for operator overloading.  It can make your code a lot more concise, making even a function call seem like a 3-hour long lecture.  But with that, you can also make the code nigh-unreadable to anybody that is new to your code.

Be very careful with this tool, and use it where it make sense, such as how “adding” two Swift Strings together makes a new string with one string first, then the other afterwards.  You can make the addition operator print to the screen, make a network request, play music, or whatever else you could write a function for, but doing any of those would be a terrible idea in production code.  You should do only what is necessary for the operator and nothing else.  If you need different things like those, make an appropriately named function that makes it obvious that it will make a network request.

Whenever you think of whether to use operator overloading, you have to ponder whether it helps your code anymore than a simple function call.  The function call may be longer, but it is a whole lot more expressive as to what it does (if named appropriately).  If it looks like you are adding, subtracting, checking equality, or whatever else the built-in operators do though, and you do it enough in your code, Swift’s operator overloading may be the right tool for the job.
[Read more…]

We’ve so far looked at 2 of the 3 named types in Swift with their own dedicated posts.  First was Enumerations in Swift, and later was Classes In Swift — An Introduction.  Now we finally talk about the third one, Structures.

Swift Structures are Value Types

Let’s just get that out there right at the beginning.  Much like the enumeration, structures are a value type in Swift.  That means that each time a structure is assigned to a constant, assigned to a variable, or passed to a function (which really is just assigning it to a constant (usually)), it is copied.  So if you set the same structure to multiple variables, and then modify one, all of the others will not change, just that one, because each new variable was a copy of the original, not a reference.
[Read more…]

I was looking for a bit of information on Tuples in Swift for an app I was working on, and decided it would be best to gather what I learn into one, easy to access place.

Tuples are a compound type in Swift, which basically means that they can hold multiple values.  A compound type can either contain what are called “named types”, which include classes, structures, and enumerations (also protocols, but since they don’t store values directly, I felt I should mention them separately), as well as other compound types.  That means a tuple can hold other tuples.  Another compound type a tuple can contain is the “function type,” which is a different way of referring to the type that describes closures (specifically the “() ->() ” style of type, which functions and methods also conform to.  That also goes the other way, that a function type can hold other compound types, like the Tuple, and other closures, which we’ve seen in my previous post Closures and Capturing Values in Swift.

While technically inaccurate, you can conceptually think of Tuples kind of like a class or structure that you can make on the fly, without having to define a full fledged class or structure (nested or otherwise).  According to Apple’s iBook though, they should probably only be used for temporary values, like to return them from a function.  It doesn’t go into detail why, but if I had to guess, they were probably optimized for quick creation, at the cost of how it stores them.  Nonetheless, one of the great new capabilities of Swift is multiple return types, and tuples are what Swift uses to achieve this, since they are technically returning a single value (the tuple itself).

One thing people are sometimes curious about tuples is how it is pronounced.  Well, according to Dictionary.com, there are two valid pronunciations.  In dictionary pronunciation code: /ˈtjʊpəl and ˈtʌpəl/.  For anybody curious, ʊ is the sound of the “oo” in “took”, ə (a schwa) is how the a sounds in “about”, and ʌ (a wedge) is the sound of the “u” in “gut.”  That means that those are pronounced (roughly) as  too-puhl and tuh-puhl, respectively.  I was digging around for examples of where they were from, only to find out both pronunciations happen for those examples as well, but they are basically from the end of words like “quadruple,” “quintuple,” and “octuple” (notice the “tuple” at the end of each).  I personally prefer too-puhl, myself.

With readers coming from the US, the UK, and many other places, I suppose the pronunciation will vary.  For those that listen to the Accidental Tech Podcast, apparently Dictionary.com agrees with both sides:  huhv-er (/ˈhʌv ər) and hov-er (ˈhɒv-/ ər).  For those of you that don’t, you really should go check it out.

Anyway though, you didn’t come here to learn about English phonetics, it’s time to learn how to use tuples in Swift!

[Read more…]

Welcome to part 2 of the Swift Extensions posts.  If you haven’t already, check out the previous post Swift Extensions Part 1 — Computed Properties and Initializers, to learn about those aspects and get an introduction to what Swift extensions are, and why you might want to use them.  The short reason is they let you extend a type for which you may not have the source code for, and you may want to do so to make working with that type easier in your own code.

Are the initializers in the main type long with a bunch of options that are unnecessary for your code?  Add your own convenience initializer that only takes the parameters you need to change, and assigns defaults to the parameters you don’t care about in the real type’s initializers.  I was making several different UIColor objects in one of my apps, and they never needed alpha changed, so I just hard-coded that to be 1.0 in an Objective-C category (the precursor to Swift extensions).  Of course, this is only really helpful if you call the longer code several times, which was the case for my app.
[Read more…]

So, there has been a reason for my most recent choice of topics to discuss.  This isn’t some grand culmination post, but the topic for today is related to several of the previous topics due to what it can do.  Back in Objective-C, you could extend classes for which you did not have the source code with something called categories.  If you are curious about Objective-C categories, I wrote about them back when this blog was still about Objective-C in my post Objective-C Categories.  This post was much earlier in my blogging career, so it may not be as polished as my current posts, so, you have been warned.

Anyway, Objective-C Categories gave you the ability to add additional methods to another class for which you didn’t have the original source code.  I used this capability in a later Objective-C post Introduction to UIColor, to create a category that made it easier to create a UIColor for my purposes.  I didn’t need to customize alpha (transparency) each time, and I wanted to use color values between 0 and 255 instead of 0.0 and 1.0, so I made a category that translated my 0 to 255 values to their 0.0 to 1.0 equivalents, and hard-coded the alpha to 1.0 (fully opaque).

These are not the same as iOS 8 extensions, such as the Today View Widgets, UIActivityViewController sharing extensions, etc.  We will cover those in a later post.

When you look at the capabilities of Swift Extensions, they are basically doing the same thing as Objective-C categories, adding methods to existing classes.  With one exception, they are all different flavors of methods.
[Read more…]