I know, sadly, that I'm getting older as there are new hires that haven't even seen The Matrix.

If you haven't seen it, well, I think you should; it is a fantastic movie. It's nice that hollywood didn't try and turn it into a trilogy…

So, what's this have to do with Swift? Excellent question!

I'll submit this for my trolling enjoyment your pondering: the Matrix is built with a static type system.

Spoon boy: Do not try and bend the spoon. That's impossible. Instead… only try to realize the truth.

Neo: What truth?

Spoon boy: There is no spoon.

Neo: There is no spoon?

Spoon boy: Then you'll see, that it is not the spoon that bends, it is only yourself.

Happy Thursday! And welcome performSelector. 🙂

Xcode 7 Beta 4 is out and it is a doozy! One of the changes is that performSelector is now available from Swift. Now, this isn't going to make your Swift types dynamic all of a sudden. However, what it does open the door for, is writing both your ObjC-style code and your Swift code all in the same language: Swift.

That's huge.

Here's some really ugly code to demonstrate:

@objc (Foo)
class Foo : NSObject {
    func bar() -> String {
        return "bar"
    }
}

let foo = Foo()
let value = foo.performSelector(Selector("bar")).takeUnretainedValue()
let result = value as? String
print("result: \(result)")

if let c = NSClassFromString("Foo") {
    let newFoo = c.alloc().performSelector(Selector("init")).takeUnretainedValue() as? Foo
    print("newFoo: \(newFoo?.bar())")
}

I'm actually pretty excited by this. This is another step closer, in my opinion, for winning in the pragmatic realm. There are certain types of problems (like a plug-in architecture) that are suited to this type of dynamic invocation.

This seems like baby steps to a great merging of the two worlds.

Update: July 23rd

It turns out, this is possible without using @objc as well:

class Bar : CustomStringConvertible {
    required init() {}
    var description: String { return "hahaha" }
}
if let c = NSClassFromString("PerformSelector.Bar") as? Bar.Type {
    let i = c.init()
    print("interesting: \(i)")
}

Just update "PerformSelector" to your module name, and voilà! For generic classes, you need to use it fist before it gets registered.

Good stuff!

Brent has a problem:

Swift protocols: http://t.co/njtgWljyy9

— Brent Simmons (@brentsimmons) July 19, 2015

//platform.twitter.com/widgets.js
His problem – protocols are seemingly messing up with mojo. It happens, and Equatable with its Self requirement can be quite annoying at times. However, his problem, at least as I understand it, is easily solvable, albeit with a bunch of code.

The key things to note about Brent's problem is that the Folder and the Feed are tightly coupled together; they have a strong type relationship together. So, we can use generics to help with this:

protocol Feed {
    var url: String {get}
}

protocol Folder {
    typealias FeedType

    var feeds: [FeedType] {get}
    func addFeeds(feedsToAdd: [FeedType])
}

class LocalFeed: Feed, Equatable {
    var url: String
    init(url: String) {
        self.url = url
    }
}

func ==(lhs: LocalFeed, rhs: LocalFeed) -> Bool {
    return lhs.url == rhs.url
}

class LocalFolder: Folder {
    var feeds = [LocalFeed]()

    func addFeeds(feedsToAdd: [LocalFeed]) {
        for oneFeed in feedsToAdd {
            if !feeds.contains(oneFeed) {
                feeds += [oneFeed]
            }
        }
    }
}

Basically, move Equatable to the type LocalFeed and every other feed type, and create a typealias on the Folder protocol so a specific type of Feed can be used.

We can go one step further, but we will see a slight problem when we do:

protocol Feed {
    var url: String {get}
}

protocol Folder {
    typealias FeedType : Equatable

    var feeds: [FeedType] { get set }
    mutating func addFeeds(feedsToAdd: [FeedType])
}

extension Folder {
    mutating func addFeeds(feedsToAdd: [FeedType]) {
        for oneFeed in feedsToAdd {
            if !feeds.contains(oneFeed) {
                feeds.append(oneFeed)
            }
        }
    }
}

class LocalFeed: Feed, Equatable {
    var url: String
    init(url: String) {
        self.url = url
    }
}

func ==(lhs: LocalFeed, rhs: LocalFeed) -> Bool {
    return lhs.url == rhs.url
}

class LocalFolder: Folder {
    var feeds = [LocalFeed]()
}

Now all Folder implementations get the addFeeds functionality for free. BUT, we have to clearly mark what could be potentially mutating. The big side-effect of this is that feeds becomes mutable outside of addFeeds, which is not good.

The way to fix this, or the only way I know how to fix this, is to create a protocol, that by convention, people agree not to use. Something like this:

protocol Feed {
    var url: String {get}
}

protocol Folder : _Folder {
    typealias FeedType : Equatable

    var feeds: [FeedType] { get }
    mutating func addFeeds(feedsToAdd: [FeedType])
}

protocol _Folder {
    typealias FeedType : Equatable
    var _feedStore: [FeedType] { get set }
}

extension Folder {
    mutating func addFeeds(feedsToAdd: [FeedType]) {
        for oneFeed in feedsToAdd {
            if !feeds.contains(oneFeed) {
                _feedStore.append(oneFeed)
            }
        }
    }
}

class LocalFeed : Feed, Equatable {
    var url: String
    init(url: String) {
        self.url = url
    }
}

func ==<T : Feed>(lhs: T, rhs: T) -> Bool {
    return lhs.url == rhs.url
}

class LocalFolder : Folder {
    var _feedStore : [LocalFeed] = []
    var feeds: [LocalFeed] { return _feedStore }
}

The _Folder protocol hides the mutation exposure of _feedStore. Oh, and while we're at it, lets change == to be generic and work for any type of Feed by default by comparing their respective url members.

Anyhow, hope that helps somewhat.

Interviewing is hard work. Somehow, in a single hour (or some other arbitrary span of time), you are supposed to give an opinion of yay! or nay! on whether to hire someone or not. Sure, sometimes they get N number of chances, but if one of those goes wrong, then what?

Unfortunately, there really are not a lot of good ways to measure a candidate's ability. Sure, a GitHub history might be ok. But honestly, I'm not going to spend hours looking through that for each candidate. Also, sometimes the code we push up to GitHub is terrible, especially as we are iterating towards a solution. So how to find the good from the bad?

Work experience… well, that's nice, but that really only spins it how the candidate wants it to be spun. I've had candidates that have clearly embellished their involvement and contributions to a project. So it's not really enough to say, "Wow, cool, you worked at Google for three years doing X! You are clearly a hire!". I also have candidates that undersell the work they've done (I typically fall into this category too).

So basically we are back to a set of interview questions where we bombard a candidate with, hopefully interesting and reflective questions. Some questions though are just not that great.

Take this classic problem: "You have 8 identical balls in every way, expect that one of them is heavier than the others. You are given an old-school balance scale; your job is to find the heavier ball."

One thing I really dislike about this question is that the interviewer is typically biased towards finding the answer in the fewest number of weighs, which to me, is a bit of a trick question (2 weighs vs. 3). Also, answers that take an iterative solution are usually looked down upon as not being correct, even though they are actually the better approach when generalizing the problem and moving it to code (and arguably in the real world scenario as well depending on the speed of your balance scale).

Here are the actual considerations of the problem:

1. The cost of counting the initial set of balls
2. The cost of partitioning the balls into various groups
3. The cost of determining the weight of each partition of balls
4. The act of "weighing" the two partitions of balls that can go on the scale

These basic steps need to be repeated until the answer is found.

Now, when dealing with physical objects in the real world, the cost breakdown is: O(n) (or O(1) if we are "told"), O(n), O(1), and O(1). We'll assume that you put the balls into a tray of some sort so moving to and from the scale is some small constant time. There's also the time it takes the balance to move, but that should also be a small constant time (afterall, the weight difference needs to be large enough that a random distribution of balls in a tray wouldn't cause a false negative).

If we are asked to implement this solution in code, the cost breakdown is this: O(n) (need to count them at least once to know), O(1) (in the best case, just index offset updates), O(n), O(1).

Notice anything in particular? You always have to touch every single ball to find out the answer. The only question is, do any of these operations have a constant time value that dwarfs the apparent O(1) cost. I'd argue no. Maybe you could make the case in the real world, but most definitely not when asked to generalize this solution to N weighted items and write the algorithm to do it.

If I were to ask this question, I would ask it exactly as I framed it above. Regardless of the path the candidate chose, I would expect them to be able to give reasons why they chose that path. However, if you gave me the binary search answer and simply told me that it is the best because it has the fewest number of weighs in it, I would simply look at you and say, "I believe I can solve it faster with more weighs".

Protocols (and their extensions)… those glorious things that they are. Well, mostly. I'm still finding a few places where they are coming up a bit short, or at least are not providing a good long-term solution.

Let's say you want to create a protocol, like I did with the Key Value Coding post.

protocol KeyValueCodable {
    mutating func setValue<T>(value: T, forKey: String) throws
    func getValue<T>(forKey: String) throws -> T
}

What this says is we want a protocol that defines a setValue() and a getValue() function. No problems here.

Now, it's time to implement this protocol.

struct Person : KeyValueCodable {
    private var kvcstore: [String:Any] = []

    mutating func setValue<T>(value: T, forKey: String) throws {
        // a bunch of logic to validate the correct type for the key and value; throw on error.
    }

    func getValue<T>(forKey: String) throws -> T {
        // a bunch of logic to validate the correct type for the key and value; throw on error.
    }

    var name: String {
        get { return getValue("name") as String }
        set { setValue(newValue, forKey: "fname") }
    }
}

Well, what happens when we want to add a new type Address that also conforms to the KeyValueCodable protocol? Well, we are going to need to implement:

1. The kvcstore for the backing store.
2. Duplicate the setValue() function.
3. Duplicate the getValue() function.

Ok, that definitely sucks. There are two ways to get around this, namely:

1. Throw away the protocol approach and use a base class with default implementations.
2. Use protocol extensions with default implementations.

Unfortunately, both have significant drawbacks. The class version forces you into reference semantics for all KeyValueCodable types, which is less than desirable. With protocol extensions, we are forced to make our internal implementation publicly exposed (well, exposed at the same access level of the protocol).

The basic problem is this: there is no way to create a protocol that is for consumers of the API and a protocol for implementors of an API. rdar://21850541

This is one of the fundamental arguments about Swift's public, internal, and private access modifiers. They do not allow for this type of design pattern, and it's necessary.

So, in this strongly typed langauge of ours, we solve this problem by convention!

protocol KeyValueCodable : _KeyValueCodable {
    mutating func setValue<T>(value: T, forKey: String) throws
    func getValue<T>(forKey: String) throws -> T
}

protocol _KeyValueCodable {
    static var _codables: [KVCTypeInfo] { get }
    var _kvcstore: Dictionary<String, Any> { get set }
}

extension KeyValueCodable {
    mutating func setValue<T>(value: T, forKey: String) {
        // default implementation goes here...
    }

    func getValue<T>(forKey: String) -> T {
        // default implementation goes here...
    }
}

That's right, create another protocol prefixed with _ and everyone knows you are up to some dirty little secret tricks that you unfortunately need to expose to everyone so they can violate all of your assumptions. Good times.

This leads me to my next problem: these default implementations are going to need to work on some data; it would be really nice if we could also create a default store in our extension so that all of the implementors do not have to do this each time to get the default behavior (rdar://21844730):

struct Person : KeyValueCodable {
    var _kvcstore: Dictionary<String, Any> = [:]
}

Just copy/paste those member fields (sure, it's just one in this example) for each type that extends KeyValueCodable. I sure hope the protocol doesn't change how it needs to store that backing information, otherwise you're out of luck.

Protocols are pretty great and made even better with extensions. However, there is still more required from to reach their potential.

I was having a discussion on Twitter with someone about KVC and creating a typed version. Well, I do not think we can create a fully type-safe version, at least not at compile time. However, we should be able to come close at runtime, I think.

Anyway, here is a stab at an implementation.

The basic protocol is simple, just setValue() and getValue() functions:

protocol KeyValueCodable : _KeyValueCodable {
    mutating func setValue<T>(value: T, forKey: String) throws
    func getValue<T>(forKey: String) throws -> T
}

However, some implementation details are necessary to support a default implementation via protocol extensions:

protocol _KeyValueCodable {
    static var _codables: [KVCTypeInfo] { get }
    var _kvcstore: Dictionary<String, Any> { get set }
}

struct KVCTypeInfo : Hashable {
    let key: String
    let type: Any.Type

    // Terrible hash value, just FYI.
    var hashValue: Int { return key.hashValue &* 3 }
}

func ==(lhs: KVCTypeInfo, rhs: KVCTypeInfo) -> Bool {
    return lhs.key == rhs.key && lhs.type == rhs.type
}

As you might be gathering, the basic premise is to use a backing store to maintain our values and type information. The implementation can then verify that the data coming in is correct.

extension KeyValueCodable {
    mutating func setValue<T>(value: T, forKey: String) {
        for codable in Self._codables {
            if codable.key == forKey {
                if value.dynamicType != codable.type {
                    fatalError("The stored type information does not match the given type.")
                }

                _kvcstore[forKey] = value
                return
            }
        }

        fatalError("Unable to set the value for key: \(forKey).")
    }

    func getValue<T>(forKey: String) -> T {
        guard let stored = _kvcstore[forKey] else {
            fatalError("The property is not set; default values are not supported.")
        }

        guard let value = stored as? T else {
            fatalError("The stored value does not match the expected type.")
        }

        return value
    }
}

Of course, the errors could be more meaningful, but I'll leave that as an excercise for the reader.

Initially I looked at using throws to capture the error. However, the usage of the code becomes quite annoying. Also, there is a fairly big limitation as computed properties (which is what we'll need for the next section), do not support throwing (http://www.openradar.me/21820924).

Ok, finally, let's implement this in a type:

struct Person : KeyValueCodable {
    static var _codables: [KVCTypeInfo] { return [ _idKey, _fnameKey ]}
    var _kvcstore: Dictionary<String, Any> = [:]
}

extension Person {
    private static let _idKey = KVCTypeInfo(key: "id", type: Int.self)
    private static let _fnameKey = KVCTypeInfo(key: "fname", type: String.self)

    init(id: Int, fname: String) {
        self.id = id
        self.fname = fname
    }

    var id: Int {
        get { return getValue("id") as Int }
        set { setValue(newValue, forKey: "id") }
    }

    var fname: String {
        get { return getValue("fname") as String }
        set { setValue(newValue, forKey: "fname") }
    }
}

All of the stored properties are put into the non-extended type. If we're using classes, this could live happily in a base class. The extension contains all of the meat, and unfortunately, all the boiler-plate code required to make this work.

And the usage code:

var p = Person(id: 123, fname: "David")
p.id
p.fname

let id: Int = p.getValue("id")
let fname: String = p.getValue("fname")

p.setValue(21, forKey: "id")
p.setValue("Sally", forKey: "fname")

let id1: Int = p.getValue("id")
let fname1: String = p.getValue("fname")

The full playground source can be found here: https://gist.github.com/owensd/82af8e362273e46d70f9.

I'll leave it up to you on how useful this is.

If you are anything like me, you were not very pleased with the print() and println() changes. While working on some other items, I realized that it's possible to shadow global functions with your own. This means that we can fix the print() and println() functions. Yay!

func print<T>(value: T, appendNewline: Bool = false) {
    Swift.print(value, appendNewline: false)
}

func print<T, TargetStream : OutputStreamType>(value: T, inout _ target: TargetStream, appendNewline: Bool = false) {
    Swift.print(value, &target, appendNewline: false)
}

func println<T>(value: T, appendNewline: Bool = true) {
    Swift.print(value, appendNewline: true)
}

func println<T, TargetStream : OutputStreamType>(value: T, inout _ target: TargetStream, appendNewline: Bool = true) {
    Swift.print(value, &target, appendNewline: true)
}

Agh! Back to sanity (at least for me).

P.S.

• I logged a bug about the behavior here: http://openradar.appspot.com/21577485.
• Full source for the above workaround can be found here: swift-fix.

Previously I was wondering how to test precondition() and assert() in my code. Well, Nikolaj Schumacher suggested something clever: shadow the precondition() and assert() functions.

My implementation his suggestion can be found here: https://github.com/owensd/swift-fix/blob/master/Assertion.swift. There is still a slight problem with this version though: normally precondition() and assert() will terminate the execution of the function, but unless you use my throwing version of those functions, your code path will continue to execute. This may or may not be a problem for you, so beware.

But wait… if we can shadow the functions and replace them with our own implementations, then this means that method swizzling is back on the table!

Here's an example:

Let's say, we have a scenario, where isEmpty on an array is just utterly broken. Too bad for us, right? Well… not exactly.

extension Array {
    var isEmpty: Bool {
        print("monkey patch!")
        return false
    }
}

let a: [Int] = []
a.isEmpty           // guess what this outputs? =)

Now, there is a caveat here… I don't know how to call the base implementation, so you're stuck with re-implementing the entire thing for member functions. For global functions though, we can fully qualify them to explicitly get the version we want.

Maybe someone else knows how to do that part?

Update, later that evening…

So, it turns out this really only works for the following:

1. Global functions
2. Properties on non-@objc types.

Oh well, and interesting hack. It does seem strange that some things can be shadowed and other things cannot.

I have a bit of a design conundrum. I have an API that looks like this:

public func next(index: ContentType.Index?) throws -> TokenizerResult<ContentType>? {
    precondition(rules.count > 0, "There are no rules specified for your tokenizer.")
    // ...
}

This belongs on a protocol Tokenizer and a default implementation is provided in an extension. The rules are static per type, at least in the default case.

So… the problem? I cannot write a test for this code because precondition fails with an uncatchable runtime exception. What I really want is a type ArrayOfOneOrMore<Element>. However, this requires a lot of code and method forwarding to work; I don't want to do that.

It seems my options are:

1. Be ok with not being able to write a test for this.
2. Relax the condition, but this hides a logical implementation error.
3. Do all of the work to implement ArrayOfOneOrMore<Element>.

Is there another option I'm missing?

Update July 9th, 2015

So I've been thinking about this some more. There is a workaround that can be done: change precondition() to assert() and compile out the assertions in a new Debug-unchecked build for testing. This keeps all of the good debugging symbols and optimizer changes at bay while still allowing for testing your code flow.

Steps to get this to work:

1. Create a new build config Debug-unchecked
2. Change the Other Swift Flags (OTHER_SWIFT_FLAGS) compiler options to -assert-config Release
3. Change precondition() to assert()
4. Update your code to handle the code path for the error state

   public func next(index: ContentType.Index?) throws -> TokenizerResult?

   assert(!rules.isEmpty, "There are no rules specified for your tokenizer.")
   		if rules.isEmpty { throw TokenizerError.NoTokenizerRulesPresent }  
   		  // ...
   		

   }

This has the benefit of raising the error immediately on failure for debug builds, providing a testing path, and still providing the error in a catchable way in release builds.

Of course, if I do this a lot, I'll probably just do this:

public func next(index: ContentType.Index?) throws -> TokenizerResult<ContentType>? {
      try assert(!rules.isEmpty, "There are no rules specified for your tokenizer.", TokenizerError.NoTokenizerRulesPresent)
      // ...
}

And create these helpers that I just use all the time:

func assert(@autoclosure fn: () -> Bool, _ error: ErrorType) throws {
    return try assert(fn, "", error)
}

func assert(@autoclosure fn: () -> Bool, _ message: String, _ error: ErrorType) throws {
    let result = fn()
    assert(result, message)
    if !result { throw error }
}

At least with these helpers it's no extra work for me. The biggest drawback I see is that it requires compiling my code again, which could suck.

Now that we have some proper error handling measures, I've been having a bit of a rough time deciding between init? and init() throws.

What I've come to realize is, my problem is really about the callsite, I actually always want to use throws. The simple fact is that I can return more information about the failure and let the caller decide if they care about it or not.

Here's an API that currently uses init?() that I think would actually value from providing the failure reason instead of just a blanket nil.

/// Construct from an ASCII representation in the given `radix`.
///
/// If `text` does not match the regular expression
/// "[+-][0-9a-zA-Z]+", or the value it denotes in the given `radix`
/// is not representable, the result is `nil`.
init?(_ text: String, radix: Int = default)

Ok, back to my usage problem example:

enum Error : ErrorType {
    case NotImplemented
}

struct Foo {
    init?(failable: Int) { return nil }
    init(throwable: Int) throws { throw Error.NotImplemented }
}

func example1() {
    guard let f = Foo(failable: 0) else {
        print("error")
        return
    }

    print("Foo(failable:) creation passed")
}

func example2() {
    do {
        let t = try Foo(throwable: 0)
        print("Foo(throwable:) creation passed")
    }
    catch {
        print("error: \(error)")
    }
}

example1()
example2()

The throws version really sucks in comparison. It's especially egregious because I'm going to be handling the failure case in exactly the same way.

Ok, so let's make it better:

func trythrow<T>(@autoclosure fn: () throws -> T?) -> T? {
    do { return try fn() }
    catch { return nil }
}

func example3() {
    guard let tt = trythrow(try Foo(throwable: 0)) else {
        print("error")
        return
    }

    print("Foo(throwable:) creation passed")

}

example3()

This gets us into a happy place again. We can turn failures where we do not care about the specific reasons into a code path that is more natural. If this becomes a pattern, it begs the question why this wouldn't be just built into the language.

Enter try?.

See this thread for some more great discussion.

// this won't compile, hypothetical syntax
func example4() {
    guard let tt = try? Foo(throwable: 0) else {
        print("error")
        return
    }

    print("Foo(throwable:) creation passed")
}

example3()

I think this is a big win. Note that while this appears to be encouraging one to ignore errors, it in fact doesn't. Many types we only care that a failure happened. This syntax simply reduces the complexity of the code when that is the case.

Also, try? is very searchable so it is trivial to audit your code for all of the uses of it to ensure error handling is indeed not needed in a fuller form.

Finally, because an Optional<T> is being returned, you are still forced into unwrapping it in order to use it.

I like it. Until we get it, trythrow() is going to be my goto.

P.S. Someone already logged rdar://21692462 on it. Great!