Optimizing Collections Book Details
Title: Optimizing Collections
Author: Károly Lo ̋rentey
Language: English
Subject: Swift / Computers & Technology / Programming / Apple Programming
No. of pages: 152
Format: PDF, EPUB, MOBILE, Source code
Recently I bought a set of all IOS books from objc.io. As you can see in the image above, which includes Optimizing Collections By Károly Lo ̋rentey. And now I want to transfer it to you for $ 50 (6 books and Video App Architecture, Advance swift and Thinking in SwiftUI) Payment Via Paypal or Bitcoin, All books are the latest version and have full source code, I will share it for you for $ 50 Includes PDF, EPUB file and full source code, Video App Architecture and Thinking in SwiftUI , you can download on Google Drive. When any book have new version i will get it free for you.
List bundle 6 books From Objc.IO
1, App Architecture + Video
2, Thinking in swiftui + Video
3, Advanced Swift + Video
4, Functional Swift
5, Core Data
6, Optimizing Collections
Please contact me by Email: truonghang0207@gmail.com.
You can see the full description 6 books at https://www.prograbooks.com/2018/06/all-ios-books-from-objcio-latest.html
Thank you
Introduction Optimizing Collections Book
Optimizing Collections in Swift
Swift’s concept of a collection is one of the core abstractions in the language. The primary collections in the standard library — arrays, sets, and dictionaries — are used in essentially all Swift programs, from the tiniest scripts to the largest apps. The specific ways they work feels familiar to all Swift programmers and gives the language a unique personality.
When we need to design a new general-purpose collection type, it’s important we follow the precedent established by the standard library. It’s not enough to simply conform to the documented requirements of the Collection protocol: we also need to go the extra mile to match behavior with standard collection types. Doing this correctly is the essence of the elusive property of swiftiness, which is often so hard to explain, yet whose absence is so painfully noticeable.
Copy-On-Write Value Semantics
The most important quality expected of a Swift collection is copy-on-write value semantics.
In essence, value semantics in this context means that each variable holding a value behaves as if it held an independent copy of it, so that mutating a value held by one variable will never modify the value of another:
var a = [2, 3, 4] let b = a a.insert(1, at: 0) ▶a
[1, 2, 3, 4]
▶b
[2, 3, 4]
In order to implement value semantics, the code above needs to copy the underlying array storage at some point to allow the two array instances to have different elements. For simple value types (like Int or CGPoint), the entire value is stored directly in the variable, and this copying happens automatically every time a new variable is initialized or whenever a new value is assigned to an existing variable.
However, putting an Array value into a new variable (e.g. when we assign to b) does not copy its underlying storage: it just creates a new reference to the same heap-allocated buffer, finishing in constant time. The actual copying is deferred until one of the values using the same shared storage is mutated (e.g. in insert). Note though that mutations only need to copy the storage if the underlying storage is shared. If the array value holds the only reference to its storage, then it’s safe to modify the storage buffer directly.
When we say that Array implements the copy-on-write optimization, Optimizing Collections we’re essentially making a set of promises about the performance of its operations so that they behave as described above.
(Note that full value semantics is normally taken to mean some combination of abstract concepts with scary names like referential transparency, extensionality, and definiteness. Swift’s standard collections violate each of these to a certain degree. For example, indices of one Set value aren’t necessarily valid in another set, even if both sets contain the exact same elements. Therefore, Swift’s Set isn’t entirely referentially transparent.)
The SortedSet Protocol
To get started, we first need to decide what task we want to solve. One common data structure currently missing from the standard library is a sorted set type, i.e. a collection like Set, but one that requires its elements to be Comparable rather than Hashable, and that keeps its elements sorted in increasing order. So let’s make one of these!
The sorted set problem is such a nice demonstration of the various ways to build data structures that this entire Optimizing Collections book will be all about it. We’re going to create a number of independent solutions, illustrating some interesting Swift coding techniques.
Let’s start by drafting a protocol for the API we want to implement. Ideally we’d want to create concrete types that conform to this protocol:
public protocol SortedSet: BidirectionalCollection, SetAlgebra { associatedtype Element: Comparable
}
A sorted set is all about putting elements in a certain order, so it seems reasonable for it to implement BidirectionalCollection, allowing traversal in both front-to-back and back-to-front directions.
SetAlgebra includes all the usual set operations like union(_:), isSuperset(of:), insert(_:), and remove(_:), along with initializers for creating empty sets and sets with particular contents. If our sorted set was intended to be a production-ready implementation, we’d definitely want to implement it. However, to keep this Optimizing Collections book at a manageable length, we’ll only require a small subset of the full SetAlgebra protocol — just the two methods contains and insert, plus the parameterless initializer for creating an empty set:
public protocol SortedSet: BidirectionalCollection, CustomStringConvertible, ↪ CustomPlaygroundQuickLookable where Element: Comparable {
init()
func contains(_ element: Element) -> Bool
mutating func insert(_ newElement: Element) -> (inserted: Bool, memberAfterInsert:
↪ Element) }
In exchange for removing full SetAlgebra conformance, we added CustomStringConvertible and CustomPlaygroundQuickLookable; this is convenient when we want to display the contents of sorted sets in sample code and in playgrounds.
The protocol BidirectionalCollection has about 30 member requirements (things like startIndex, index(after:), map, and lazy). Thankfully, most of these have default implementations; at minimum, we only need to implement the five members startIndex, endIndex, subscript, index(after:), and index(before:). In this Optimizing Collections book we’ll go a little further than that and also implement forEach and count. When it makes a difference, we’ll also add custom implementations for formIndex(after:), and formIndex(before:). For the most part, we’ll leave default implementations for everything else, even though we could sometimes write specializations that would work much faster.