My original article — “Protocol-oriented Data Structures in Swift 4: A Generic Doubly Linked List” — was published on appcoda.com.
Let’s talk about creating a list on steroids, i.e., a generic doubly linked list in Swift. For our purposes here, a list is a software receptacle that contains related data that we’re interested in inspecting, organizing, manipulating, etc. A doubly linked list stores a list of “nodes.” Each node contains data, knows about the preceding node in the list, and knows about the following node in the list. We’ll talk about adding nodes to the list, removing nodes from the list, displaying information stored in nodes in the list, and traversing the list. I’ve used the term generic because you’ll see that I can store store pretty much every built-in or custom Swift type in my linked list, like
CGAffineTransform… You can even store a collection of instances of a custom class or struct in my list (see section “Storing custom types” below). Most importantly, I’ll show you how to move towards generic programming, also known as generics, parametric polymorphism, templates, or parameterized types, where, when possible, we can write code that applies to many types, and thus reduces code redundancy.
Continue reading “Building a generic doubly linked list using protocol-oriented Swift 4”
Those of you who’ve used Objective-C and Swift for any meaningful length of time must be familiar with the
self property of structs and classes. I’m not sure how many are aware of the
Self “type” (sometimes called a “requirement”). I would be very interested in knowing how many understand the difference between
Self. I’m talking about
self with lower-case “s,” which I’ll call “small self” herein. It’s pretty well documented. Similarly,
Self with an upper-case “S,” is what I’ll call “tall self” herein. It’s not very well documented.
Continue reading “Self versus self in Swift 4 – capital “S” and lowercase “s””
Notice that Swift almost seems to frown on making a copy of a reference type, i.e., a copy of an instance of a class, or, as some would rather put it, getting a copy of an object. I’m not talking about getting another reference to a class, I’m talking about getting an entire, separate copy of a class instance. This frowning on class copying is not an accident. Swift’s language architects want the syntax and semantics of the language to be crystal clear. They want developers to be confident that reference types and value types will both have 1) distinct and obvious meanings and that both types will 2) behave consistently. But still, why not be able to safely make a copy of a class instance? I’ll show you how in this tutorial by borrowing the copy constructor concept from C++. In Swift, we’d call this a “copy initializer.” (NOTE: Yeah, yeah, yeah, I know about
NSCopying in Cocoa and Objective-C.)
Continue reading “Class copy constructors in Swift 4 for defensive copying”