In my previous post I’ve explained that the new Codable protocol of Swift 4 has some problems with references to objects (i.e. class instances). Or, better said, the two implementations of coders available
have this problem: they expand all references to new objects and create doublets if references in the object tree occur more than once for a single object. In the case of loops in the object tree (references of objects to each other) the encoding leads to an endless loop.
The old NSKeyedArchiver/NSKeyedUnarchiver of the Objective C-world do not have this problem: they respect references and restore them correctly at unarchiving. So, I want to implement this old way, i.e. the NSCoding protocol in my LinkedList as well. Remark: LinkedList uses references to its payload as well even in loops but that is taking care of even in the use of the Coding protocol.
Maybe you have read my series of posts about LinkedLists. It was great fun for me to put these things together, but recently, I stumbled over a problem with serialisation, esp. the Codable protocol and references to objects. In Swift 5 there are two Encoder/Decoder pairs available:
It turns out that these encoders are not really suitable for archiving object graphs because they expand all references to objects, i.e. put the objects instead of the references in the archive. If you have a simple tree of objects and you do not care about doublets that may be fine but as soon as you have loops in your object graph you are in trouble. Encoding such a graph with these two encoders lead to an endless loop. This may happen quite frequently; just think about delegation where you typically have references of the delegate and its master against each other.
So, now Swift 4 is here and things are changing. One of the big improvements of Swift 4 is the incorporation of serialisation for classes, structs and enums. In contrast to the previous versions which rely on the old NSObject/NSCoding mechanisms the new Codable protocol is not restricted to classes only. And even better, if you do not have special needs the compiler will synthesise the needed functions for you as we will see later.
Just for completeness I’d like to show in this post how to make structs serializable in the same manner as enums (see this post). Again, we transform the struct to a dictionary of NSCoding compliant types and give it to an NSCoder (e.g. NSKeyedArchiver) for coding. The other way round we get the decoded dictionary and initialize the desired struct with it. Sounds simple, doesn’t it. Let’s start.
Welcome to this new posts in my series about enums with associated values. In the previous posts we looked at the equatability of enums with associated values. Another problem arises when we want to store enums (maybe as part of the model) on a file or want to send it over a network, let’s say: want to serialize the enum. Although the primitive types as Int and String conform to the NSCoding protocol as well as collections of those types (e.g. Arrays and Dictionaries) enums and structs don’t. And since they are not classes we can also not implement the NSCoding protocol for them. For simple enums we can use its raw values for coding, but that’s not possible for enums with associated values.