By:
Comments Off

Removing Ads

For the past few years, I've been running this blog with small advertisements on the side (or above if you're on mobile). I've decided to remove them.

I've been blogging a lot more recently with my personal issues with depression, and I've gotten a lot of feedback from readers. People who are supportive of me (thanks for writing – I really appreciate it!) and people who are themselves struggling. I don't feel comfortable selling ad space against this kind of personal content. They'll be gone by the end of June.

I wish Fusion Ads all the best. They've been very kind to me, and if I ever want to sell ads against one of my web properties again, I'll likely return to them.

/Ash Furrow /Comments Off
By:
Comments Off

Expression Interpretation Problem with Swift Closures

I was working with someone on an open-source testing framework for Swift and we came across the following problem. If the last statement in a closure can be interpreted as an expression, then the Swift compiler will try and interpret that as the return value for that closure, which can conflict with an expected type.

Let's take a look at an example.

Cosider a function a that does some operation, then returns true or false depending on the success of that operation.

func a() -> Bool {
    /* do some work */
    return true
}

Cool, so far so good. Let's now take a look at a function b that takes a closure that takes no parameters and doesn't return a value.

func b(closure: () -> ()) {
    closure()
}

Still OK. Now let's invoke b with a closure that invokes a.

b{
    a()
}

Boom, compiler error.

Cannot convert the expression's type '()' to type 'Bool'

Interesting. It took us a few minutes to understand what was going on. The invocation of a returned a Bool, so the compiler was inferring that the closure should return a Bool, too, leading to a type-mismatch. Remember that the last expression in a closure is interpreted as an implicit return statement. So the compiler was interpreting this as follows.

b{
    return a()
}

The workaround is the convert the expression a() into a statement that the compiler will ignore.

b{
    var _ = a()
}

Kyle pointed out this would fix the issue, too.

b{
    var _ = a()
    return
}

Interesting. I've filed a radar about it and I expect it'll be fixed soon.

/Ash Furrow /Comments Off
By:
Comments Off

A Familiar Form

Last week, Apple introduced a brand new programming language for iOS and OS X development, called Swift. During WWDC, I attended every Swift presentation and spent time in the labs chatting with the engineers responsible for this new language. While I've had less than a week's exposure to this new language, I have some thoughts.

Generally, I'm impressed. Swift is the kind of radical departure from the existing Objective-C language that I was hoping for. Sure, it's a radical departure, but is it radical enough?

Swift gets rid of a lot of cruft of Objective-C syntax while keeping some of its key features, like named parameters, around. But it also keeps around things that aren't necessarily a good thing. Let's take a look at a basic example.

func compute (x: Int) -> Int {
    return x*x
}

compute(4) //prints 16

This is a basic function definition and a corresponding invocation. A few things jump out that should be familiar to Objective-C developers. First, we have brace brackets delimiting the scope of the function. Lots of languages do this, but plenty don't, as well. We also see a familiar, C-like syntax for invoking the compute function.

Swift could easily have looked like this, a more Haskell-friendly syntax.

func compute x: Int -> Int 
   x*x

compute 4 //prints 16

Less familiar, sure, but would be just as valid if you're designing a whole new language.

When I asked an Apple engineer about these kinds of constructs, his answer was that familiarity with existing Objective-C developers was an important factor in the design process of the language.

Familiarity is important, certainly. We need existing developers to embrace Swift in order to avoid a situation where this new language languishes. However, while it's important for the sake of developer adoption, will it lead to the best language possible?

Maybe. Maybe not.

I feel that Apple may be making compromises on the language design for the sake of familiarity with developers, sacrificing what could be an even better syntax for the sake of developer penetration. Maybe this is the right choice, maybe it's not. I hope that they know what they're doing, and I hope that future revisions of the language aren't burdened with these familiarity considerations.

/Ash Furrow /Comments Off
By:
Comments Off

ReactiveCocoa 101 at AltConf

I had a great time this week presenting about ReactiveCocoa at AltConf. Check out the video here.

/Ash Furrow /Comments Off
By: Comments Off

Swift Initializers

Swift, Apple's new programming language for iOS and OS X, makes several significant departures from Objective-C. What I found to be particularly interesting are the new semantics surrounding object lifecycles. Here are the key points:

  • Formalizing convenience and designated initializers.
  • Formalizing sequence of operations for initializers.
  • Enforcing language-level, compile-time enforcement of these new semantics.

I'm going to cover each of these in depth, with examples. Let's dive in!

Initializers In-Depth

In Objective-C, things are pretty loosey-goosey when it comes to how you construct your initializers. For instance, you could call super, or not, or call init on an entirely different class. You can set up ivars and properties before you init, even though you're not supposed to, and while you're actually not supposed to access methods or properties inside any init method, everybody does. It's really the wild west.

That's not the case in Swift. Swift has a very clear, specific sequence of operations that are done in initializers. Let's start with some basic examples are work our way up to a general case.

Let's take an object A. We'll define it as follows.

class A {
    var x: Int
    init(x: Int) {
        self.x = x
    }
}

Notice that A does not have a superclass, so it cannot call a super.init() function as it does not exist.

OK, so now let's subclass A with a new class named B.

class B: A {
    var y: Int
    init(x: Int, y: Int) {
        self.y = y
        super.init(x: x)
    }
}

This is a departure from Objective-C where [super init] would typically be called first before anything else. Not so in Swift. You are responsible for ensuring that your instance variables are in a consistent state before you do anything else, including calling methods (which includes your superclass' initializer). Neato.

But there's one more hitch. Say that we want to make sure that x is always set to a value computed by a method in our class? We can't call a method on B until we call super's init. We'd actually write something like this.

class B: A {
    var y: Int
    init(x: Int, y: Int) {
        self.y = y
        super.init(x: x)
        self.x = self.generate()
    }

    func generate() -> Int {
        /* return some value */
    }
}

That's right. If you want to access a superclass' property,you must do so after calling super.init() in order to give the superclass a chance to set them first.

In general, a Swift object initializer looks like the following:

init(/*parameters*/) {
    // set own properties, if necessary
    // call super.init()
    // set superclass' properties, if necessary
}

Convenience and Designated Initializers

Swift formalizes the common Objective-C pattern of designated initializers into something checked at compile-time. This is actually really, really cool. Let's take a look at a new class hierarchy.

class A {
    var x: Int
    convenience init() {
        self.init(x: 0)
    }
    init(x: Int) {
        self.x = x
    }
}

init(x: Int) is the designated initializer for this class and all other initializers in A must have the convenience. Convenience initializers can call other convenience initializers, or the designated initializer.

Let's take a look at a subclass. This is where things get interesting.

class B: A {
    var y: Int
    convenience init() {
        self.init(y: 0)
    }
    convenience init(y: Int) {
        self.init(x: 0, y: y)
    }
    init(x: Int, y: Int) {
        self.y = y
        super.init(x: x)
    }
}

Convenience initializers in a subclass may only call other initializers in their own class. Only the designated initializer may call an initializer on the superclass.

Missing Objective-C-Style Semantics

Swift departs from Objective-C initializers. Consider the old style initializer.

-(instancetype)init {
    self = [super init];
    if (self) {
        // setup
    }
    return self;
}

There are a few distinctive parts to a classic Objective-C initializer. First, you need to assign self to something, either your superclass' initializer or another initializer on self. Then we check if the reference to self is valid (maybe the initializer that we called returned nil). We do some setup, then we must return self.

In contrast, Swift initializers are very straightforward. Initializers don't return self, so you don't need to return self. Cool! However, this has a implication. In Objective-C, if initialization fails, we can return nil in order to indicate that failure. Since Swift initializers don't return a reference to self, this approach is not possible.

I spoke with an Apple engineer at the Swift Lab at WWDC and asked about the pattern. He indicated that this was not currently possible. Instead, we should use factory methods that return an optional type.

class A {
    class func anything() -> A? {
        return A()
    }
}

He indicated that they're working on building something into the language, since initializers are the preferred way to create instances (as opposed to factory class methods). For now, this works well if you need this kind of failing initializer pattern.

Neat! Swift has really embraced the conventions that Cocoa and CocoaTouch developers already know and incorporated them into the language-level with compile-time checks.

/Ash Furrow /Comments Off
By:
Comments Off

Initial Thoughts on Swift

Yesterday, Apple announced a brand new programming language as a replacement for Objective-C called Swift.

Super cool. I wrote about replacing Objective-C a few months ago, and I'm glad to see this update from Apple. Here was my list of criteria for a "good" replacement:

  1. It shouldn't use pointers, structs, header files, anything C-based
  2. It should be a memory-managed language (No ARC, not retain/release, no Core Foundation)
  3. It should have native, unicode strings and native collections
  4. It should be concise
  5. It should have named parameters

It looks like everything except memory-management has been checked off, and I haven't played around with it enough to determine if it's new memory management system is up to snuff, but from what I've seen so far, I am very impressed with Swift.

I'm very impressed with Apple's book on Swift. It's great that this stuff isn't sealed under NDA.

I'm planning on writing at least one book on Swift, which will be out in the coming months. While I'm impressed with the resources Apple has released, I think that there is room for some third-party resources, too.

/Ash Furrow /Comments Off
By:
Comments Off

Feels

It's been a while since I've written on here, in part because I've been busy at work, in part because I've been on other writing assignments, and in part because my depression has gotten the better of me since adjusting my medication a few months ago.

However, the past week has been amazing. I've been in San Francisco in the lead up to Apple's WWDC next week. I've been spending time with some amazing people and making new friends, while growing closer to existing ones. I've been so filled with energy after seeing so many mates again for the first time in years, in some cases. It's been great.

I met with a doctor a few weeks ago to adjust my medication for something better suited for me. I think it's starting to work. I've begun talking openly about my depression with my friends (previously it was only really mentioned on this blog), and they've all been super-supportive. I'm lucky to be surrounded by such awesome people.

Anyways, you probably won't hear from me again for a few weeks. I'll be busy at the conference, and then writing some iOS 8 tutorials which'll stay under wraps until the NDA lifts. I'm confident that I'm turning the corner on this and, while it's been really hard over the past few months, I feel like I'm on the mend.

/Ash Furrow /Comments Off
By:
Comments Off

Core Data Course

I'm really excited to tell you all about my new Core Data Course at Treehouse.

The course covers the basics of Core Data and includes steps to create a re-usable, general-purpose Core Data stack. It covers what managed objects are and where they live in a typical Core Data stack, and much more. I had a blast recording this course and I hope that you enjoy it.

Check out the trailer video for more.

/Ash Furrow /Comments Off
By:
Comments Off

Mobile Couch

Last week I was on the Mobile Couch Podcast discussing ... you guessed it, ReactiveCocoa! This is similar to my iPhreaks episode, but is more introductory. Plus I love an Australian accent. Check it out!

/Ash Furrow /Comments Off
By:
Comments Off

Up and Running with MindSea

Earlier this year, I worked with a fantastic company in Halifax named MindSea. I had a great time working with them remotely and I did a little write-up about my time with them, talking about proper abstractions and modularization. You can read my post here.

/Ash Furrow /Comments Off