Playgrounds

 
14
Dec
2015
 

Swift Type Constrained Extensions: Express Yourself

by Matt Long

I admit it. I was pretty down when Swift was announced. I appreciated the finer points of the reasons for it, however, they weren’t convincing–at least not to me–not at first. I denied that it was actually “expressive” as the overall community was referring to it, however, that was before version 2. It’s at the point when the lights went on for me. I am now a convert and this post explains why–at least one of the reasons. The only question I ask now is while you can do some really cool expressive things, should you? You’ll see what I mean if you read on.
(more…)

 
5
Nov
2014
 

Swift and valueForKeyPath: You Can’t Keep A Good API Down!

by Matt Long


tl;dr; Download the Value For Key Path Playground


I was incredibly disappointed in Swift when I started to look into how key value coding might be preserved in the transition from Objective-C. Of course, Apple would preserve that, right? And I don’t mean by resorting to using Foundation classes–you know all type-casty and everything (yeah, type-casty). Are we progressing forward or looking to the past, after all? I shouldn’t have to rely on NSArray like this:

Right? Who wants to do that? What’s the proper Swift way?

Well, my early assumption from what I was seeing in Swift was that valueForKeyPath: was gone and no longer did we have a convenient way to grab only the fields we needed from a collection of objects. It appeared that it couldn’t be done–at least not in any idiomatic elegant way. Then I downloaded some sample code from the Apple developer site and noticed they were doing what I needed, but using map to do it. The answer was map. Here’s an example:

Now the lastNames variable contains a list of strings with just the last name property of my items array. Given an array of dictionaries like this, you can see how that is providing pretty much what we used to get from valueForKeyPath:

lastNames now contains:

Notice we also have an address property that points to a dictionary. If want to get the street property inside of address, we can drill down the same way:

Now, you can see we had to force-unwrap the address property in order to access the street property. This works perfectly and is a fine replacement for valueForKeyPath: of old. When the call succeeds we now have all of the street addresses in the streetAddresses array:

Take a look at the Value For Key Path Playground if you want to see it in action.

What About Safety?

In Objective-C, if you message nil, it’s a no-op. In Swift, however, if we unwrap an optional that is nil, we will crash. So, on this line:

when we unwrap using the bang ! operator, if that value doesn’t exist, we’re in trouble. Say our data was changed to this:

Notice the address field has been changed to addr. This causes a crash.

Playground Crash

Meanwhile, with the old Foundation way, we do this:

but look what the output is. NSNull!

No crash. So which is better?

Well, if your data can be unpredictable, which really shouldn’t happen, then the Foundation outcome is “safer” from a crash perspective. However, your data should be nailed down, so a crash would actually tell you what’s wrong with your data pretty quickly.

What, though, is the safe Swift way of handling this? We can coerce our objects to optionals and use optional chaining instead:

So our first optional operator says to return the object or nil and the second operator says that is should be an optional of type String. This call returns an array of optionals that has this output in our playground:

Assuming the following data:

Notice the first two use the bad addr field and the last two use the correct address field.

For my applications, I think I would prefer to see a crash so I know my data is bad. It’s the server developer’s problem. Am I right? ;-)

Taking Map() Farther

The map() function really goes far beyond this trivial little valueForKeyPath: replacement example. You can really massage your data into any form you want with it. Say for example you wanted to create an transformed array of dictionaries from your array of dictionaries that had some of the same data, but organized differently. For example:

This returns an array of dictionaries that contain a single key value pair with a key called full_name and value of the first name and last name of each item in the original array concatenated together. The output looks like this in our playground:

As you can see, there really are a lot of possibilities for massaging your data structures using map. The tough part is imagining how it might be used and often that just comes from experience. The more you use it, the more obvious the solutions will become.

Swift Is Not So Bad

There are certain complaints about Swift I still have, however, I am finding that it is growing on me. I am starting to have much more success making my code pure Swift–pulling back from my old habits and considering how problems should be solved in this brave new Swift world. It’s getting better and some of the language aspects are actually better than Objective-C. I couldn’t see that forest for the trees just a couple short months ago. Until next time.