The Matrix

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

Neo saying 'Woah'

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. 🙂

The Matrix

Dynamic Swift

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!

Dynamic Swift

Brent’s Feed Protocol Problem

Brent has a problem:

//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.

Brent’s Feed Protocol Problem

Interview Questions

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".

Interview Questions

Protocols and Hidden Details

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.

Protocols and Hidden Details

Key Value Coding in Swift

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.

Key Value Coding in Swift

Fixing print() and println()

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.

Fixing print() and println()