Functions on Andrew Bancroft

Working with Swift: Adopt a Protocol or Pass a Function?

Thu, 05 May 2016 17:59:16 +0000

Without fail, any time Rob Napier (@cocoaphony) speaks or writes, I gain insight into new and deeper ways to solve problems with Swift.

In January 2016, he gave a talk at dotSwift, and I wanted to record my thoughts on something he said that made a lot of sense when it comes to the topic of, “Should I create and adopt a protocol for this Type I’m creating, or should I just pass it a function instead?”

Two insights

During the talk, he compared some scenarios that were meant to help determine when to create a protocol, or when doing so would be overly complex, and passing a function might be the simpler thing to do instead.

Two phrases caught my attention:

A protocol is really just a promise to implement some functions, and a struct is mostly just a bundle of functions that implement the promise.

and

I can pass you an object that promises a function, or, I could just pass you the function.

[mind blown]

So in other words, there are times when, rather than going through the formality of…

Creating a protocol defining one or more functions that should be implemented
Creating a Type that adopts that protocol to promise that “I (as a class/struct/enum) will implement this/these function(s)”
Creating an instance of that Type
Passing off the instance to another Type that needs to call that promised function

…life might be simpler and code might be more clear and more concise when you just… pass the function instead!

When to pass a function

Rob gave us a couple or three rules of thumb. Not hard-and-fast, “It should always be this way”, but just some guiding thoughts to filter our decision-making about our architecture.

When it comes to finding opportunities that lend themselves to going the “just pass the function” route, consider the following:

If you’re creating a Type that depends on a single piece of functionality (a single function), maybe try depending on / passing just the function, rather than creating a protocol.
If you’re creating a Type that depends on more than a single function, but the nature of the dependent relationship is short-lived, maybe try depending on / passing just the function. How do you know if it’s short-lived? Ask, “How many times am I going to call the function(s) that I depend on? Once, and then I’m done? Or multiple times throughout the application life-cycle?” If it’s a once and done kind of relationship, much like a callback, then perhaps just depending on and passing the function, rather than creating a protocol, is the simpler route.

When to use a protocol

For some rules of thumb when it comes to choosing a protocol over just passing a function, you might consider:

If you’re creating a Type that depends on 3 or more related functions, wrapping those functions up in a protocol might be cleaner and more clear.
If you’re creating a Type that depends on some functions for a long period of time, consider a protocol. Long-lived relationships are better-described in a protocol. Think of something like a table view’s data source. This is a good example of when to use a protocol to describe the dependency and the relationship, because as data changes, the table view will need to constantly call into those protocol methods to refresh itself.

How to depend on a function

In order to fully grasp how to go the “just depend on / pass the function” route, you need to have an understanding of how function Types are described in Swift. With this knowledge, you’re set to do a couple of things:

1 – Create a property on the Type you’re implementing that is of some function Type. For example:

 1struct Vehicle<Fuel> {
 2    let move: (Fuel) -> Void
 3}
 4
 5// Fuel Types
 6struct Gas {}
 7struct RocketFuel {}
 8
 9let car = Vehicle<Gas>(move: { _ in print("use gasoline to move") })
10
11let rocket = Vehicle<RocketFuel>(move: { _ in print("use rocket fuel to move") })
12
13car.move(Gas())
14rocket.move(RocketFuel())

A full explanation of indicating function Types can be found by reviewing my guide on Swift Functions as Types

2 – Declare that such-and-such parameter on a function within your Type must be a function Type. For example:

1func getData(completion: (NSData) -> Void) {
2    let data: NSData = // do something to go get data
3
4    // call completion handler when getting data is done
5    completion(data)
6}

The above is an example of a callback scenario, which I give full treatment in Fundamentals of Callbacks for Swift Developers

Swift Functions as Types

Fri, 18 Mar 2016 18:11:02 +0000

For the well-versed functional programmer, the fact that [functions in Swift are Types][1] is no surprise. But I’m relatively new to the game on that front, so when I first encountered the idea of thinking of a function as a Type back when Swift was announced in 2014, it was a real eye-opener for me.

Swift Types (in general)

In order to understand functions as Types, it’s probably a good idea to know what folks are talking about when they use the term “Type” in a general sense.

In Swift, we’ve got two kinds of Types when we talk about them generally:

Named Types
Compound Types

Named Types

Named Types are those which are defined and identified by the name that they’re given. Classes, structs, enums, and protocols fit this category of Type.

To define a Named Type, you’d do something like this:

1class SomeNewClassType {}
2
3struct SomeNewStructType {}
4
5enum SomeNewEnumType {}
6
7protocol SomeNewProtocolType {}

Initializing instances of Types and using their properties and methods, passing them around to functions that require parameters of those Types, or setting them as values to properties of other Types are all pretty standard thoughts that come to mind when using named Types.

Compound Types

Compound Types, on the other hand, don’t have names. Rather, they have “signatures” that define and identify them as Types. Swift has two compound Types: functions and tuples.

Now I know what you might be thinking: “Functions have names!”

Indeed many do. But when we’re thinking about them in terms of their Type-ness, we’ve got to go beyond the name to the function’s “signature” characteristics.

The name of a function (or tuple, since they can be type-aliased) is simply how we refer to the function in code to execute it or pass it around as an argument.

The “signature” of the function, however, is the part that characterizes the function as a Type.

I want to analyze what I’m talking about when I refer to a function’s “signature”, because that really is as the heart of my goal for this blog entry…

Function Types

What exactly makes up a function’s Type-ness or “signature” as I’ve been calling it? Two things:

The Type(s) of its parameters
The Type that the function returns

Combining the Type(s) that the function receives as inputs, and the Type that it returns composes to give the function its Type / “signature”.

Reading a function’s Type

It always helps me to visualize, so take apart an example.

If you’ve lived long on the Internet, you’re bound to have run across a Star Wars name generator… Plug in your name, and maybe a birth year, and out comes some crazy “Star Wars name” for you.

The function definition (minus the body) might look like this:

1func generateStarWarsName(firstName: String, lastName: String, birthYear: Int) -> String { 
2    // ... 
3}

If someone were to ask you, “What is the generateStarWarsName function’s Type?”, you could answer: “generateStarWarsName is a function Type that has three parameters, the first two of Type String, the last of Type Int, and that returns a value of Type String.”

Wordy? Yes. But it does explain in precise terms what the function’s Type is.

Function Type notation

Rather than write out the paragraph describing the function’s Type, it’s far more convenient to indicate a the Type of a function using a standard notation. This notation is also the syntax that the Swift compiler uses when it’s trying to work with function Types.

Essentially, it boils down to stripping away the function’s name and the parameter names to leave behind the raw Type information that composes to give the function its Type.

Given the above generateStarWarsName function, we could notate its Type as follows:

(String, String, Int) -> String

See how that works?

Remove “generateStarWarsName”, “firstName: “, “lastName: “, and “birthYear: ” and you’re left with that raw Type information. What remains is the function’s Type notation.

It tells you (and the Swift compiler) everything you need to know to be able identify the Type of that function… it’s “signature”, if you will.

Gotchas

A couple of gotchas when it comes to notating a function’s Type:

1 – If a function takes no parameters, the “parameter portion” of the Type notation will simply be () with nothing between the parentheses.

So for example, the Type notation of
func returnHelloString() -> String {}
is () -> String.

2 – If a function has no return type (ie, it doesn’t return anything), the “return type portion” of the Type notation will be -> Void.

So for example, the Type notation of
func sayHello() {}
is () -> Void, since it takes no parameters, and returns nothing.

Practice

Here are a few more examples for you to practice function Type identification. Can you write out the correct notation for each function’s Type?

1func complimentMe(name: String) -> String { 
2    // ... 
3}

Show answer

`(String) -> String`

1func countToTen() { 
2    // ... prints 1 to 10 to the console ...
3}

Show answer

`() -> Void`

Notice that while `countToTen` doesn't have the "-> Void” in its definition, it is listed in the function's Type notation for clarity.

When you read this function's Type, you'd say, "This is a function Type which takes no parameters and returns Void.”

1func addInts(first: Int, second: Int) -> Int { 
2    // ... 
3}

Show answer

`(Int, Int) -> Int`

1func fadeIn(duration: NSTimeInterval, delay: NSTimeInterval, completion: (Bool) -> Void){ 
2    // ... 
3}

Show answer

`(NSTimeInterval, NSTimeInterval, (Bool) -> Void)) -> Void`

This one's actually a more complicated "compound Type” – note the third parameter which indicates that `fadeIn` receives a function Type as one of its inputs. Remember that since functions are Types, they carry the characteristic of being able to be passed around to other functions as parameters, or stored in variables/constants!

<p>
</p>

```swift

func increment(input: Int) -> Int { return input + 1 }

func decrement(input: Int) -> Int { return input - 1 }

func chooseAdjustmentFunction(increase: Bool) -> (Int) -> Int { return increase ? increment : decrement }

    
    <p>
      <a id="show-answer-5" style="cursor: pointer;">Show answer</a>
    </p>
    
    <div id="answer-5" style="display: none;">
      increment: `(Int) -> Int`<br /> decrement: `(Int) -> Int`</p> 
      
      <p>
        chooseAdjustmentFunction(_:): `(Bool) -> (Int) -> Int`
      </p>
      
      <p>
        This one's complicated in a slightly different way. This time, it's the return Type of the function that's kind of crazy.
      </p>
      
      <p>
        Read this as, "A function Type which takes as Bool as a parameter and returns a function Type which takes an Int as a parameter and returns an Int.&#8221;
      </p>
      
      <p>
        You can see how the Types of the `increment` and `decrement` functions <em>match</em> the return Type of the `chooseAdjustmentFunction` function. </div> 
        
        <h1>
          Wrapping up
        </h1>
        
        <p>
          Knowing that functions are Types in Swift is a powerful thing. Being able to correctly articulate the Type of a function, and produce its notation in valid Swift syntax is even <em>more</em> powerful, because it's at that point when you'll be able to recognize which kinds of functions are valid to pass as parameters to <em>other</em> functions, or to assign as properties of other Types. It can also play a role in Swift's pattern matching features. But alas, those topics for another day!
        </p>
        
        <p>
          <a name="related" class="jump-target"></a>
        </p>
        
        <div class="resources">
          <div class="resources-header">
            You might also enjoy&#8230;
          </div>
          
          <ul class="resources-content">
            <li>
              <i class="fa fa-angle-right"></i> <a href="https://www.andrewcbancroft.com/2015/01/06/immutable-types-changing-state-swift/" title="Immutable Types with Changing State in Swift">Immutable Types with Changing State in Swift</a>
            </li>
            <li>
              <i class="fa fa-angle-right"></i> <a href="https://www.andrewcbancroft.com/2015/01/20/conveniently-transforming-immutable-types-swift/" title="Conveniently Transforming Immutable Types in Swift">Conveniently Transforming Immutable Types in Swift</a>
            </li>
          </ul>
        </div>
        
        <p>
          <a name="share" class="jump-target"></a>
        </p>
        
        <p>
        </p>

 [1]: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html#//apple_ref/doc/uid/TP40014097-CH10-ID158

Clean Coding in Swift – Functions

Thu, 07 Aug 2014 18:16:23 +0000

I’ve been thinking a lot about how the principles of clean coding (Bob Martin’s “Clean Code”) apply in Swift. How do I express clean code in this language? Conversely, how do I avoid writing cryptic code in Swift? What language features help me write clear and self-explanatory code and what language features present the potential for tempting me to write obscure code in Swift?

I am beginning a commentary series that I hope will encourage clean coding practice in myself and in the Swift developer community. Dialog on these topics is welcomed – I have not “arrived”, so please – help me help the Swift community for the better!

The first in the series is on writing clean functions in Swift. As it turns out, Swift provides some really great mechanisms for defining self-explanatory, clear-purposed functions. We’ll start by analyzing the features around naming functions and their parameters, and will conclude on thinking through function decomposition.

Function Names

Something that I really enjoyed about Objective-C was that while method names were often long and verbose, they were extremely descriptive. My code often read like a narrative, and I enjoyed that. Some may have hated it, but I found it extremely helpful in facilitating my recollection of a method’s intended purpose and the expectations around its argument requirements.

I do my best to think hard about the names that I give my functions, ascribing to them a name that is specific, targeted, and focused on the single “thing” that each one does. Nothing in Swift mandates that we leave the verbosity of Objective-C naming conventions behind. In fact, the exact opposite is true! One example is that swift intentionally provides us with the ability to add external parameter names so that we can be as descriptive as we need to be about the names of our functions.

Parameter Names

Swift’s external parameter names, in my opinion, are wonderful for helping write self-documenting code. They simply help guide my mind back to what a given function does and needs in order to do its job. Anything to help me get back in the zone is worth spending a few extra keystrokes on, especially since Xcode’s auto-completion assists me so well when calling functions with long signatures.

Apple recommends the following:

Consider using external parameter names whenever the purpose of a function’s arguments would be unclear to someone reading your code for the first time.

I would only add that sometimes, that someone “reading your code for the first time” is you. Not technically, of course, but think about this: Write some code, leave it, and come back to it some time later. Will it make sense? Will you immediately go, “Ah, I know what I meant there”, or will you do like I’ve often done and say, “WHAT in the WORLD was I THINKING??!?”.

Spending a few seconds on typing a few more words to save brain power and potentially more seconds/minutes some time later is a worthy investment. And if you work on a team, your teammates will appreciate the extra care you put in to providing as many hints as possible through inventing good names. Good naming includes parameter names. Why not take advantage of the fact that Swift provides you this opportunity to write self-documenting code?

Function Decomposition

In order to make sure our functions are doing “one thing”, we need to make sure that the statements within our function are all at the same level of abstraction. -Bob Martin, Clean Code pg. 36

This is just general advice without respect to a specific language. A couple of things to think about:

Watch out for key words like “and” / “or” in your function names. These red-flag words often indicate that your function is doing more than one thing and can be further decomposed. Consider:

1func washAndDryCar() {
2    // Logic to wash and dry a car
3}

A preferred decomposition could look something like this:

1func washCar() {
2    // Logic to wash a car
3}
4
5func dryCar() {
6    // Logic to dry a car
7}

Doing one thing can still involve multiple steps. But if each step takes a few steps of its own, that group of steps can be extracted out into another function. Consider:

1func washCar() {
2    // Pre-rinse code (example implementation - 4 lines)
3    // Soap code (example implementation - 5 lines)
4    // Rinse code (exmple implementation - 4 lines)
5}

A preferred decomposition might look something like this:

1func washCar() {
2    rinse(durationInSeconds: 25.0)
3    soapCar()
4    rinse(durationInSeconds: 60.0)
5}

What’s neat about the final result of the decomposition is that not only is my washCar function shorter and more readable (from 13 lines to 3 lines), but I got code re-use by making the rinse< function take a duration argument.

Hopefully these thoughts spark a few ideas in you. Constructive feedback is welcome! How are you thinking about writing clean code in Swift?