One should always kick off their morning with some light reading! Mine this morning is Type Variance in Swift by Alexandros Salazar. So many people are accoustomed to Apple’s Objective-C 2.0 I don’t think they remember the days of ObjC 1.0. Good times, what I began using for the object oriented aspects of my kernel. I had a crazy idea I could use the Objective-C dispatching as an RPC mechanism into kernel space through the system call interface. It worked reasonably well from a functional standpoint but I was never quiet satisified from a secruity standpoint. Apparently standpoint is a single word.

Back from the tangent and nose to the article. Intresting, in the explorations of the article Mr. Salazar, he concludes member and global functions are covariant first class functions (those passed to other functions) are contravariant. He demonstrates generic types are invariant which is interesting. I would imagine with a simple delcaration these invariants could quickly be expanded to accept covariant forms. Mr Salazar leaves off saying most developers wouldn’t need to be concerned with these techniques. I’m on the fence as my expierence with long running well structured programs tend towards more generic statemnets over time and allows a developer to capitalize on prior work. Expressions of type variance tend to be a supporting reason for adding generic expressions to a langauge.

To bind the context of my exploration I was hoping to propose changes to mtynior/SwiftyLogger to allow the DefaultLoggerFactory to use a builder pattern like in the documentation for the addTarget method. In order to accomplish this and retain knowledge of the implementation (or anywhere down that type tree you are) I would need to be able to express the return type as the implementation. These types of patterns are not uncommon in the implementation of the more complicated construction pattenrs in the gang of four book when implemented in modern languages.

Alright, I’ve spent enough time playing aorund with these ideas. As much as I would love to introduce a generic types to resolve the issue I think it will create an interface harder to implement and use. For now I’ll drop back to expecting covariant return types. Definitely still fight using a structured refactoring approach, I keep wanting to do more in a single commit than I really should. Single small operation, test, commit, repeat. That should be my process for dealing with chnages.

So I’ve gotten SwiftyPaperTrail to boot and properly log messages in my application. Now I just need to restore the default setup with the logger printing to the console.

I really wish I knew why OSX crashes with two external screens attached on resume :-/.


So I realized I have several edge cases I overlooked. The first problem is reconnection on failure. Not only does PaperTrail document this a standard behavior, it’s also the only way it communicates that something went wrong. The second is we log a lot of text, including many new line characters. PaperTrail caps a single message at 1024 octets. At this point and time I’m fine with the SwiftyPaperTrail truncating larger messages with a warning. Easy enough to fix both of those.

Upgrade blues

Or, more specifically: lack of upgrade notifications. I wasn’t given really clear reproduction cases, so I’m unsure what is really going on here. The idea is the server knows what it’s compatability level is with this particular client and to ensure a decent user expierence we are forced between making the user upgrade or being entirely unsupported. Or choice was to force the user to upgrade. So first case is to tyr to identify failure reasons behind this IPC call failing.

Realm seems decent over all, I haven’t had to deal with it much. But I do have a problem with what is probably our usage. When switching back to a previous version of the application I can almost certainly say Realm will crash every time. I have to reset the simulator every time. Well, there isn’t anything obvious, so unforunately I’m going to have to punt until I get steps to reproduce.