| /** | |
| How to get a method which takes any string enumeration in Swift 2.1. | |
| Actually figured out by Carl Hill-Popper, documented by me. | |
| */ | |
| import UIKit | |
| // 1) Make you some string enums. |
| import CoreData | |
| protocol Fetchable | |
| { | |
| typealias FetchableType: NSManagedObject | |
| static func entityName() -> String | |
| static func objectsInContext(context: NSManagedObjectContext, predicate: NSPredicate?, sortedBy: String?, ascending: Bool) throws -> [FetchableType] | |
| static func singleObjectInContext(context: NSManagedObjectContext, predicate: NSPredicate?, sortedBy: String?, ascending: Bool) throws -> FetchableType? | |
| static func objectCountInContext(context: NSManagedObjectContext, predicate: NSPredicate?) -> Int |
Here's my own list of the interesting stuff announced during this year's WWDC, collected from the keynotes, various Apple docs, blog posts and tweets.
If you're planning to watch the videos, I really recommend this Mac app that helps you download and watch them: https://github.com/insidegui/WWDC.
http://www.apple.com/osx/elcapitan-preview/
| // (c) 2015 Nate Cook, licensed under the MIT license | |
| // | |
| // Fisher-Yates shuffle as protocol extensions | |
| extension CollectionType { | |
| /// Return a copy of `self` with its elements shuffled | |
| func shuffle() -> [Generator.Element] { | |
| var list = Array(self) | |
| list.shuffleInPlace() | |
| return list |
When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.
So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.
Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?
I'm going to cover three things in this post:
| Your goals are to reduce the number of things that you have to keep in your head at any given moment, and to rely as little as possible on your own ability to consistently do things right. | |
| If you make a thing immutable ('let' in swift), you never have to think about what happens if it changes, or what other parts of the code you'll effect if you change it. | |
| If you split complex functions into several smaller functions that only interact by passing arguments or getting return values, then you limit the amount of code you need to consider when hunting for a bug, and you can test each small piece separately. | |
| If you understand what things must be true in your code (aka invariants, for example "a person's age must be greater than 0"), and either provide no function that can cause them to be untrue, or check and crash immediately when they're untrue, then you don't have to debug issues caused by incorrect assumptions. | |
| If you remove possibilities (for example, Swift removes the possibility of things being nil unless |
| Copyright 2015 Chris Eidhof | |
| Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: | |
| The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. | |
| THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHE |
| func unwrap<T1, T2>(optional1: T1?, optional2: T2?) -> (T1, T2)? { | |
| switch (optional1, optional2) { | |
| case let (.Some(value1), .Some(value2)): | |
| return (value1, value2) | |
| default: | |
| return nil | |
| } | |
| } | |
| func unwrap<T1, T2, T3>(optional1: T1?, optional2: T2?, optional3: T3?) -> (T1, T2, T3)? { |
| // | |
| // CollectionViewDataSource.swift | |
| // Khan Academy | |
| // | |
| // Created by Andy Matuschak on 10/14/14. | |
| // Copyright (c) 2014 Khan Academy. All rights reserved. | |
| // | |
| import UIKit |
