Swift Diary #4: KVC Again

Al Skipp wisely writes (in reply to my post about KVC):

It's still the case that Stringly typed code is a pain in the Aris to write/debug/maintain.

True. So true.

But let me remind you of a place where most iOS and Mac developers do it all the time: Interface Builder.

Interface Builder is a Very Fancy XML Editor

Some developers eschew Interface Builder (IB) altogether. That’s fair. I myself don’t automatically reach for it — there are times when a UI is so simple that it doesn’t need it, or it’s too dynamic to be expressed well in IB. So I at least think about it before I go there. But I do use it plenty often.

And I’d bet that most developers use IB at least a little bit, if not a lot, in their apps. (Though maybe not for games.)

And what you do you do in IB? You type (or copy-and-paste) in the class name of your view controller. You click checkboxes and set attributes. In the end you’re just setting a bunch of strings that gets stored in an XML file.

In the end, you get things like this:

<buttonCell key="cell" type="square" bezelStyle="shadowlessSquare" image="gear" imagePosition="only" alignment="center" borderStyle="border" inset="2" id="1194" customClass="TransparentButtonCell">

You don’t want to do edit that directly, of course, so you have IB. But this is still what you end up with.

Runtime

Nib loading uses KVC. Though it may not use setValue:forKey: directly, it does the conceptual equivalent.

That does not mean that you can only interact with your objects via valueForKey: and setValue:forKey:, of course. It’s just that instantiating uses KVC. Your own code is still foo.bar = 7 and so on.

The alternative to KVC (or something much like it) — commence shuddering now — would be code generation instead. (Those of you who’ve been through that on other platforms, come out from under your desk. It’ll be okay.)

Trade-offs

Of course, it is a pain when you’ve mistyped — or just plain forgot to type — the name of a class in IB. That’s a drawback of any system like this.

But we’re willing to make the trade-off because the productivity gain we get from using IB is worth the occasional issue like this. The nice thing about bugs like that is that they’re usually caught very quickly, and are just a normal part of the development process. It’s what we do for a living.

If IB can do it, why can’t I?

It’s a pretty nice system. I get to declare things rather than write code — and though I have to take care that my declarations are correct, I still end up saving time and writing and maintaining less code. It’s a win.

The Core Data modeler is another example. I don’t have a handy example, but I bet it generates XML (or maybe JSON or, more likely, plists). And the runtime uses KVC and KVO (and method generation, which is another topic) to make it all work.

It’s only natural that I might want to write similar systems for my own use. And I have. In the case of the database and model object code that I’ve written, I don’t have a fancy modeler — I just edit a plist. Though editing is more raw, the concept is the same: I type in class names and map database columns to types and property names.

And my code — which I can reuse unchanged in as many apps as I want to — uses KVC to put it all together. As IB does.

The rest of my code — the code outside my database code — doesn’t use KVC. I still write foo.bar = 7, rather than [foo setValue:@7 forKey:@"bar"]. I can rely on the compiler to tell me when I’ve made an error in the rest of my code.

So, in the end, this stringly-typed database/model-object code is way less of a pain to write, debug, and maintain.

In fact, I don’t touch it at all, since it’s debugged and working.

But I’d still love to make it work with pure Swift objects and structs.

Swift Diary #3: Arrays, Protocols, and Pointer Equality

Let’s say I’m writing a Finder replacement. (Disclaimer: previous statement may or may not be true.)

The common representation of the file system in a GUI app is a tree. A common pattern, then, is to create a tree data structure. The tree is made of Node classes, and each Node has a representedObject which conforms to the NodeRepresentedObject protocol.

A representedObject may be a Folder or a File. All the Node class knows is that its representedObject conforms to NodeRepresentedObject.

Each Node has zero or more children. The children are Node objects also. The children’s representedObjects are a mix of Folders and Files.

* * *

Here’s the trouble I ran into. Given a representedObject and an array of Nodes, I wanted to find the Node with that representedObject.

Things to know: the representedObjects are uniqued (a file system folder has one Folder object; a file system file has one File object). And, because they’re uniqued, they’re also objects rather than structs.

Because this is true, I can use pointer equality on representedObjects.

The Objective-C code might look like this:

- (Node *)existingChild​WithRepresentedObject:​(id<NodeRepresentedObject)​representedObject {
  for (Node *oneNode in self.children) {
    if (oneNode.representedObject == representedObject) {
      return oneNode;
    }
  }
  return nil;
}

Pretty simple.

* * *

My first go at doing this in Swift looked like this:

func existingChild​WithRepresentedObject​(representedObjectToFind: NodeRepresentedObject) -> Node? {
  for oneChild in children {
    if oneChild.representedObject === representedObjectToFind {
      return oneChild
    }
  }
  return nil
}

This didn’t compile: I get the error error: binary operator '===' cannot be applied to two NodeRepresentedObject operands.

“But,” I thought, ”shouldn’t pointer equality always work?”

Well, no. Not if representedObject is a struct.

So it occurred to me that I have to tell Swift that these are both objects, and it works:

if (oneChild.representedObject as! AnyObject) === (representedObjectToFind as! AnyObject)

* * *

But I don’t like using as! — as Rob Rhyne writes, “But every time you type !, someone at Apple deletes a Radar.”

So I figured there must be a better way. And there is.

  1. Keep the original line as it was: if oneChild.​representedObject === representedObjectToFind.

  2. Make NodeRepresentedObject conform to the AnyObject protocol, which lets the compiler know that representedObject is an object, so that pointer equality testing will work:

protocol NodeRepresentedObject: AnyObject {

It works. See the gist.

* * *

Here’s the part I don’t totally like: to make this work, it required bringing in Objective-C. AnyObject is an @objc protocol.

So here’s my question: is there a way to do this without bringing in Objective-C?

(I feel like there are two Swifts. Swift + Objective-C is like writing Objective-C with a new syntax. Pure Swift is another thing. I’m pragmatic, and I’ll use the former as needed — but I want to learn the pure Swift solutions.)

* * *

Update 10:15 am: the answer came quite quickly from Matt Rubin on Twitter and others:

try: protocol NodeRepresentedObject: class { … }

Done! It works.

* * *

Update 10:40 am: and there’s also this, which I didn’t know, from Joe Groff on Twitter:

AnyObject is marked '@objc' for obscure implementation reasons, but it is a native Swift feature.

How to Hang Mail, TextEdit, and Contacts

We often get crash reports where the crash happens outside our code and we can’t reproduce it. (Like every developer, I’d bet.)

While our users often tell us what they were doing when submitting a crash log — thanks! it helps a ton — those steps don’t always have the one key thing we need to be able to reproduce the crash.

But today we got one from a helpful OmniGraffle user: hit the Return key really, really fast.

We tried it, and we reproduced the crash. Then reproduced it in other of our apps, then reproduced it in Mail, TextEdit, and Contacts. (And stopped there.)

So I decided to title this post “How to Hang Mail, TextEdit, and Contacts,” because it’s more universal than “How to Crash OmniFocus.” But I’d bet this works on a fair number of apps, Apple’s and not Apple’s.

Before you try it, fair warning: you will have to force-quit TextEdit. When I did this on 10.11, things went weird and I had to reboot.

Here’s what to do:

  1. Launch TextEdit.

  2. Start a new document.

  3. Type a few characters.

  4. Save it to your Desktop.

  5. Choose File > Export as PDF… and have it export to your Desktop.

  6. Choose File > Export as PDF… again — and select the file you just exported to. (As if you’re going to overwrite it.)

  7. Hold down the Return key. TextEdit will hang after a few seconds. You’ll have to force-quit it.

  8. Open Console. You’ll see something like this:

7/22/15 3:28:25.441 PM TextEdit[866]: *** Assertion failure in -[NSWindowCentricRemoteView maintainProcess​NotificationEventMonitor:], /SourceCache/​ViewBridge/​ViewBridge-105/​NSRemoteView.m:1356

Note: to make this work, you may have to have your Keyboard key rate set fairly high in System Preferences > Keyboard. (Mine is at second-fastest.)

Also note: the PDF part is a red herring. It has nothing to do with PDF. That just happened to be a handy example.

Also note: you can do the same thing use Save As… in TextEdit and get a slightly different weird behavior.

rdar://21949944

Update 4:20 pm

It may not hang on 10.11 b4. You might see some display strangenesses — like black rectangles where a sheet used to be. And you may see notes in Console from com.apple.appkit.xpc.​openAndSavePanelService.

Swift Diary #2: KVC

I was very glad to hear that performSelector and friends are supported in Swift in the latest Xcode 7 beta. But what I want to talk about today is a similar thing: Key-Value Coding (KVC).

I use KVC in a critical part of my apps: the part that creates model objects from database rows.

The database code is generalized and shared by multiple apps. I create a mapping (using a plist) that maps SQLite table names to property names and types.

The object creation code goes through the mapped property names and does the right thing for each name. In the end it boils down to something like this:

[modelObject setValue:​someValueFromDatabase forKey:​propertyName];

(This even works for non-object properties, which is brilliant on the part of KVC’s designers.)

I can do this in Swift, too. (Note that this is unchecked code, and I could have the syntax wrong.)

modelObject.setValue​(someValueFromDatabase, forKey:propertyName)

There are plenty of other places where KVC makes sense. (It’s part of a hearty, dynamic breakfast.)

Another example might be mapping NSTableView cells to values — a columns’s identifier might be configured to be the same as a property name, and so it’s easy to get the desired value:

modelObject.valueForKey​(columnIdentifier)

The coupling here is quite loose, and the compiler isn’t going to tell you if you’ve mistyped a property name. You’ve got all kinds of rope here.

But I’m totally comfortable with that. Here’s the deal I’m willing to make: to make my code more elegant (read: smaller, easier to maintain, reusable), I’m willing to let it crash if I’ve configured things incorrectly.

A bug here — say there’s a typo in a property name in my database mapping — will mean an instant crash, as the object has no such property name. I’m good with that. Crashes like that have zero chance of living beyond the time it takes me to build and run.

* * *

If this is available in Swift, then why am I writing about it?

Because this is not a pure Swift thing: it’s a Swift + Objective-C thing. You can’t do this with structs, for example.

I want to get the advantages of structs. There are plenty of cases where my model objects could be structs. Structs are cool.

We’re in a transition period right now. Swift needs Objective-C so that people who rely on the dynamic nature of Objective-C — like me, like many developers — can write their apps.

It would be best, though, if Swift didn’t have to carry Objective-C baggage with it forever in order to make it adequate for the job of app-writing. I don’t think it will, even.

So my case is that Swift itself needs things like this. If not a clone of KVC, then something very much like it.

Manton News

The esteemed Mr. Reece has gone indie!

Just the other day I described Manton and me as litter-mates. I’m proud of him for taking this leap.

Swift Diary #1: Class or Struct from String

Like Mike Ash and his Friday Q&A blog posts, I take requests from readers. Unlike Mike Ash, all I have is questions.

This one comes from my co-worker Jim Correia, and is related to a question I posted on Twitter last night about instantiating an object whose class is known at runtime rather than compile time.

For reference, here’s the answer to last night’s question.

Jim takes this one step further: what if all you have is the class name as a string?

This isn’t an academic question — it’s something app developers do. For example, do a Show Package Contents on any Omni app and look inside Info.plist — you will likely find class names in the plist. (Example: see OFControllerClass in OmniFocus’s plist. Also look inside the OIInspectors array.)

This is a useful pattern when you have a general framework of some kind and you want to configure it for a specific app. The framework doesn’t know which specific classes to use, so you tell it.

And then, in the code, at some point it comes down to doing an NSClassFromString(s) to get a class, and then instantiating an object.

I want to do the same thing in Swift, but with additional criteria:

  • I don’t want to have to mark the class an Objective-C class. I want to use pure Swift.

  • I want to be able to use structs interchangeably with classes. Whether the thing is a class or a struct is a detail that’s private to the class or struct, and not something the general framework needs to know.

I realize that this may seem marvelously unsafe to some people. But, in practice, it’s not. And it’s super-common. (And it’s not terribly different from working with Interface Builder, where you configure by typing in class names.)

I’ll update this post with the answer. (I assume there is one.)

* * *

Update 10:05 am: @jckarter writes:

Possible, but not implemented yet.

Secret Projects Diary #3: Decision to Make

Both my secret-project apps are very dynamic. (They both even have plugin architectures, so that people besides me can extend the apps in significant ways.) The designs call for heavy reliance on protocols — protocols all over the damn place.

Now I’m faced with a decision. Even though there are solutions to my earlier post regarding Swift and protocols, there are lots and lots of places that need solutions.

And those solutions require more code than I was expecting to write. More code means more code to maintain and more places for bugs to hide. And those solutions don’t have — I hate to say it — the elegance of Objective-C.

I was hoping that I could use protocols in Swift in much the same way I do in Objective-C. That is, just as Objective-C doesn’t care about the difference between id<Foo> and ConcreteFoo *, Swift wouldn’t care about the difference between Foo and ConcreteFoo. But that’s not the case.

* * *

I feel like a putz every time I write “I’m going to use Technology X!” and later write “No I’m not!”

People tease me about it (which is fine).

But I’m not a curmudgeon. I’d never call myself a graybeard (despite the actual gray that appears when I skip a day shaving). I like new things.

Here’s the thing: I have a responsibility to choose the best tool for the job, knowing that the best tool is the best tool for me, at this time, on this specific job.

And I like writing about these decisions, on the grounds that my actual circumstances will be different from yours but that it’s good exercise to follow along with other people’s engineering decisions. (Well, I certainly get a benefit from reading what other developers write, at least.)

* * *

Here’s one way to think about it: how much grief will I put myself through trying to get my protocol-heavy Swift code to work and make it good code and elegant?

* * *

Here’s another way to think about it. If Objective-C didn’t have the ability to treat id<Foo> and ConcreteFoo * in the same way, and suddenly Swift had that ability, would we be talking about how this feature is really, really cool? A game-changer? The best thing since type inference?

I think so.

So is it smart to cast aside Objective-C, which already has this (and other) wonderful features, just because it’s not the new thing?

Except that it’s not just that Objective-C isn’t the new thing. It’s also not the future thing. Switching isn’t a matter of if but of when.

And I want these apps to last a long time.

* * *

In the end, it took me writing it up to decide to stick with Swift.

Expect more blog posts.

Solving Problems I Don’t Have, Except that I Do Have Them

I’m not sure if I’ve said it on my blog, but I’ve said it in person to other people: Swift’s type system solves a problem I don’t have.

Example: if I make an NSArray, I know what’s in there, my code knows what’s in there, and I’ve never had a crash or other bug where the array contained something unexpected.

Seriously. This isn’t that hard.

Except that that’s not actually true.

* * *

There are two cases where that hasn’t been true, and they’re representative, I think.

One is in JSON parsing: I’ve ended up with NSNull in an array or dictionary where I expected something else — and then I’ve sent it a message expecting it to be an NSString or whatever, and the app crashed.

So that’s a thing: data from the outside world may be weird.

That being said, Swift doesn’t necessarily help very much. Or maybe it does, but I’m not good enough at Swift yet to realize how it helps. Totally possible. But right now, for me, there’s always a point where I’m surprised to be forcing a cast and then looking around nervously to see if the atmosphere ignited.

There’s a second case where I think it does help. I wrote a crashing bug in Objective-C (and fixed it moments later; it didn’t ship) where I expected everything in an NSArray to be of the same type, and it wasn’t true.

The code was building a pull-down menu, and the zeroth item was an NSDictionary with a value for key @"name", and other items were of an object type that had a name property. Every object would respond to valueForKey:@"name" as expected — but not to obj.name. I didn’t realize what was going on at first, and Swift absolutely would have helped.

Now — the original code wasn’t written by me, and I wouldn’t have done it that way, but it’s not necessarily wrong. Just different from my style.

But it’s a fact of life that apps very often have more than one author, and sometimes many more than one, and with different styles. And they may be separated in time (the original author may not even be working on that app; they may not even be at the company any more).

While Swift makes it harder to write type-related bugs — which is great — it also makes it harder, sometimes, to do what I want in a reasonable and simple way, which is not great.

However, it improves with each release. And if there are trade-offs which make the choice of language a tie, the tie-breaker has to be the question: which technology is the future?

(That presumes that the choice of language is a tie. It may or may not be. It differs with each person and each app, and it changes with every release of Swift.)

Secret Projects Diary #2: Swift 2.0 Protocols

Let’s say I’m writing an RSS reader. (This is the example I tend to use on my blog, for historical reasons, and shouldn’t be taken as indicative of anything.)

Let’s say the RSS reader can have a mix of stand-alone feeds and feeds that are synced with FeedBin, Feedly, NewsBlur, etc. I might very well do this:

  • Create a Feed protocol.
  • Create classes for each different type of feed: LocalFeed, FeedBinFeed, FeedlyFeed, etc. Each one of these conforms to the Feed protocol.

(Why? Because each syncing system is different, and rather than have a giant Feed class that can handle all the different types, it’s smarter to have a Feed protocol and then specific implementations for each different type of feed.)

RSS readers tend to have folders too. But folders may have different rules, depending on the system: folders inside folders may or may not be allowed, for instance. So, similarly, I might do this:

  • Create a Folder protocol.
  • Create classes for each different type of folder: LocalFolder, FeedBinFolder, FeedlyFolder, etc. Each one of these conforms to the Folder protocol.

The Folder protocol includes the following:

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

Now, in a concrete implementation of addFeeds, I want to check that each feed isn’t already contained in the folder.

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

But I can’t: I get Cannot invoke 'contains' with an argument list of type '(Feed)'.

Okay, I think — let’s just use a Set anyway. Probably should have been a Set all along.

So I change the Folder protocol to make feeds a set:

var feeds: Set<Feed> {get}

And on that line I get an error: Type 'Feed' does not conform to protocol 'Hashable'.

So I try to make the Feed protocol Equatable, and I can’t. (And it has to be Equatable to be Hashable.)

* * *

I believe in protocol-based programming. Big, big fan. But it’s here where I get frustrated.

It occurs to me that I’m still new to Swift, and I’m trying to use Objective-C patterns. That’s fair and true.

The Objective-C version of all of this is pretty natural, though. Given Feed and Folder protocols, I can do this:

- (void)addFeeds:(NSArray *feedsToAdd) {
  NSMutableArray *feedsArray = [self.feeds mutableCopy];
  for (id<Feed> oneFeed in feedsToAdd) {
    if (![feedsArray containsObject:oneFeed]) {
      [feedsArray addObject:oneFeed];
    }
  }
  self.feeds = [feedsArray copy];
}

(A version where self.feeds is an NSSet is even simpler.)

It occurs to me that there probably is an answer in Swift. But it probably means more code. Objective-C syntax may be more verbose, but the fact that I can treat id<Feed> as an object without having to stand on my head is important because, again, I’m a huge fan of protocol-based programming. (And I’m a huge fan of less code.)

Let’s just say that I’m doing it wrong. What’s the right way to do this?

* * *

Aside:

“Brent — if you love Objective-C so much, why don’t you marry it?”

Here’s the deal: I’m 47 years old, and if I start ignoring new things, I’ll fall behind and won’t be able to catch up. When you’re 30 or even 40 you can safely ignore things for a while and catch up later. Later on it’s harder and time is shorter. So I’m learning Swift.

And, by the way, I’m enjoying it. There’s so much to love. But sometimes I hit roadblocks and Swift’s type system feels like a straightjacket — and then I miss the elegance of my beloved Smalltalk-derived Objective-C.

* * *

Update 11:25 am: I created a playground showing my conundrum: RSSReaderExample.playground.zip. (May require Xcode 7 beta.)

The Liscio Approach to Variants in Swift

In two recent posts — see how we keep calm and carry on? We’re back to tech topics — I wrote about implementing variants in Swift 2.0.

(See Swift question: Enum vs. Struct for Variants and, before that one, Swift Protocols Question.)

In both cases I was definitely thinking like an Objective-C programmer — I was thinking about how to wrap native types in a variant type.

One approach was to use an enum with associated types, which is much like using tagged unions in C. Another approach was to create a different struct for each under-the-hood value type and have them all conform to a Value protocol.

Chris LiscioCapo author (Capo is genius, FYI) — suggested another approach: Don’t wrap. Don’t box. Just use the native types directly.

That is, instead of creating something like this…

protocol Value {
  func valueBySmashingOtherValue​(value: Value) -> Value
}

BoolValue : Value {
  let value: Bool
  func valueBySmashingOtherValue​(value: Value) -> Value {
    // do something and return a Value
  }
}

IntValue : Value {
  let value: Int
  func valueBySmashingOtherValue​(value: Value) -> Value {
    // do something and return a Value
  }
}

etc.

…do this instead:

protocol Value {
  func valueBySmashingOtherValue​(value: Value) -> Value
}

extension Bool : Value {
  func valueBySmashingOtherValue​(value: Value) -> Value {
    // do something and return a Value
  }
}

extension Int : Value {
  func valueBySmashingOtherValue​(value: Value) -> Value {
    // do something and return a Value
  }
}

etc.

That is, extend the native types instead of wrapping them.

In Objective-C you can’t extend BOOL or NSInteger since they’re not object types, but in Swift you can extend Bool and Int and similar types.

At my stage in learning Swift I wouldn’t have thought of this — but Chris did. (Thanks, Chris!)

(The advantages of this approach are, I hope, self-evident.)

PS The code above hasn’t been checked to see if it compiles. (Written directly in MarsEdit.) But you get the idea.

PPS I am frequently tempted to write that Objective-C is my lightsaber. But I don’t think that’s fair. I think it’s more that I’m still learning how Swift can be elegant — and Chris’s approach here counts as an instance of elegance.

Archive

Ads via The Deck