Swift Extensions and Information Hiding

Apr 25th, 2015

Andrew Bancroft tested and analyzed the behavior of extensions in Swift.
While his findings aren’t utterly surprising, having them summed up in this nicely done article certainly helps.

In a nutshell:

extensions in the same file as their source can access even privat members (attributes and methods, that is)
extensions in different files can access internal and public members – but only if they are in the same module
if extensions are in a different module, they merely have access to public members
classes with public or internal visibility on themselves expose their members as internal by default
classes with private visibility on themselves expose their members as private
extensions themselves don’t have to be public for public members to work (unlike classes)

This has consequences for your tests: they reside in a separate module, so they can only access public members of your classes.

If you extend classes from static libraries, the same holds true. Different module, only public accessors.

Success and Error Callbacks in Objective-C: a Refactoring

Apr 17th, 2015

I’m refactoring code of Calendar Paste 2 some more. Since I like what I learned using Swift so much, one of today’s changes was about making a view controller method do less by factoring object creation and error handling into its collaborators. The resulting code handles far less of the action involved. Instead, it delegates the action to a new command-like object. And instead of querying an event template for data and assembling an actual event with start and end dates, it delegates event creation to the template itself. Tell, Don’t Ask saved the day.

Return Types can Capture Async Processes and Failures

Apr 16th, 2015

I’ve written about using the Result enum to return values or errors already. Result guards against errors in the process. There’s also a way to guard against latency, often called “Futures”. There exist well-crafted solutions in Swift already.

Book Updates for Swift 1.2

Apr 14th, 2015

I have just updates the book Exploring Mac App Development Strategies to Swift 1.2. A few sections were expanded, a few paragraphs rewritten – but the big update is still underway. It’s due this summer, and then I’ll consider the book feature-complete. Until then, check out the current deal for Creating Multi-Process Mac Applications, which is available at a discount right now since it’s an early release version.

Functional Programming in Swift (YouTube Videos)

Apr 11th, 2015

After the latest change in my diet, I eat a lot more often throughout the day and try to spend the time watching educational talks to make use of my time. Functional programming seems to not only be all the hype – its concepts seem to reach mainstream thinking, too. Here’s a collection of talks you might find worth your while.

Functional Swift – conference recordings with tons of great stuff
Erik Meijer: What does it mean to be Reactive? – taught me a lot about being explicit and honest in my return types
Neal Ford: Functional Thinking – how to use data transformations instead of a series of instructions
Erik Meijer: Functional Programming – shows what being stateful entails

If you got some useful talks, share them in the comments!

Event Publisher Revision 1

Apr 10th, 2015

I have imported my latest event publishing code into the Word Counter. Since the DomainEventType enum didn’t provide much value besides obtaining a notification name, I decided to get rid of it and obtain a name by another means.

In the current iteration (see the Gist), the event protocol reveals a static eventName. I also removed the duplicated notification factory from concrete events:

import Foundation

public typealias UserInfo = [NSObject : AnyObject]

public protocol DomainEvent {
    class var eventName: String { get }

    init(userInfo: UserInfo)
    func userInfo() -> UserInfo
}

public func notification<T: DomainEvent>(event: T) -> NSNotification {
    return NSNotification(name: T.eventName, object: nil, userInfo: event.userInfo())
}

It’s weird that I have to write notification<T: DomainEvent>(event: T) to access static properties of the event type. notification(event: DomainEvent) doesn’t work as of Swift 1.1., because “Accessing members of protocol type value ‘DomainEvent.Type’ is unimplemented”.

In a similar vein, a method like this doesn’t satisfy the generics requirement:

func foo(event: DomainEvent) {
    let notification = notification(event)
    // ...
}

But this does:

func foo<T: DomainEvent>(event: T) {
    let notification = notification(event)
    // ...
}

Mixing protocols and generics makes me wonder where the problem lies, but hey, it does work this way, although generics pose a slight performance penalty to protocols if I remember the WWDC talks correctly.