So far, I have enjoyed Swift. I’m still a bit curmudgeonly about having to explain – in great detail – what I want to the compiler like it was a small child that keeps asking “Why?,” but there is value to it.

swiftcastToolboxLogo-2c3da670c8b08578e92f2d265eadaf63

There are some nuances to bridging between Objective-C and Swift that are a bit distracting, and the current state of bridging is probably the best it’ll ever be. So, our goal is to write all new applications purely in Swift and leave Objective-C behind.

To me, there are three things that, if added to Swift, would make the nostalgia of leaving the language I cut my teeth on more bearable.

1. Real Reflection Libraries

We didn’t really think of Objective-C as using reflection, but the real power of Objective-C was that reflection was sort of built into the language and Foundation. Being able to instantiate classes from strings, KVC, the underlying foundation to Core Data, categories, using selectors to trigger methods, and the Objective-C runtime library – these are all things that other languages typically expose through a reflection library.

Right now, it looks like reflection exists within Swift to simply support playgrounds. When Swift has a strong reflection library, we’ll be able to stop saying “Aargh, this would be so much easier/possible in Objective-C!”

 Related: Optional Protocol Methods in Pure Swift

2. Custom Attributes and Metadata

Currently, Swift supports some built-in declaration attributes like @NSManaged, @objc and @autoclosure. Marking declarations with an attribute provides some context to the declaration that can be used at compile or runtime to modify behavior. Coupled with a strong reflection library, custom attributes can allow us to associate our own context with a declaration. This allows for some powerful metaprogramming. The following is a useful thing to do in languages that have custom attributes and reflection:


class Person: JSONRepresentable {
	@JSON("name")
	var name: String?
	
	@JSON("person_id")
	var id: Int?	
}

With this, I have one handy method for decoding JSON into JSONRepresentable objects. Going a step further, I’d have my code generate xcdatamodel files from attribute metadata. Having to update both the Core Data file and the managed object subclass in code is a nuisance and prone to error, just like anything in programming where one has to duplicate things.

3. Closurization of Accessor Methods

In Swift, I can get a reference to a method and then call that method later:


class T {
    func action() {
        print("Something happened to (self)!")
    }
}
let t = T()
let tAction = t.action
let tActionCurry = T.action
// These 3 are all equivalent:
t.action()
tAction()
tActionCurry(t)()

But accessors (setters and getters) don’t behave this way:


let t = T()
let tProperty = t.name // This, as you might expect, returns the name and not the getter for the name.
let tPropertyCurry = T.name // This is a compiler error

 

There are all sorts of useful things that could be done with this feature. Granted, a fully featured reflection library would provide this type of functionality, but I think that having it through a syntactic-sugary mechanism would also be useful.

 

Joe Conway

Founder at Stable Kernel

Leave a Reply

Your email address will not be published. Required fields are marked *