Author: Chris Lattner
import Foundation | |
func findFiles(rootPath: String, suffix: String, ignoreDirs: Bool = true) -> [String]? { | |
var result = [String]() | |
let fileManager = FileManager.default | |
if let paths = fileManager.subpaths(atPath: rootPath) { | |
let swiftPaths = paths.filter { $0.hasSuffix(suffix) } | |
for path in swiftPaths { | |
var isDir : ObjCBool = false | |
let fullPath = (rootPath as NSString).appendingPathComponent(path) |
public class Channel<Value> { | |
private class Subscription { | |
weak var object: AnyObject? | |
private let notifyBlock: (Value) -> Void | |
private let queue: DispatchQueue | |
var isValid: Bool { | |
return object != nil |
Edit: This list is now maintained in the rust-anthology repo.
- Proposal: SE-XXXX
- Authors: Chris Lattner, Joe Groff
Modern Cocoa development involves a lot of asynchronous programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.
This paper introduces a first class Coroutine model to Swift. Functions can opt into to being async, allowing the programmer to compose complex logic involving asynchronous operations, leaving the compiler in charge of producing the necessary closures and state machines to implement that logic.
// Created by Vasily Ulianov on 09.02.17, updated in 2019. | |
// License: MIT | |
import Foundation | |
/// Subclass of `Operation` that adds support of asynchronous operations. | |
/// 1. Call `super.main()` when override `main` method. | |
/// 2. When operation is finished or cancelled set `state = .finished` or `finish()` | |
open class AsynchronousOperation: Operation { | |
public override var isAsynchronous: Bool { |
// | |
// CoreDataController.swift | |
// | |
// Created by Keith Harrison http://useyourloaf.com | |
// Copyright (c) 2017 Keith Harrison. All rights reserved. | |
// | |
// Redistribution and use in source and binary forms, with or without | |
// modification, are permitted provided that the following conditions are met: | |
// | |
// 1. Redistributions of source code must retain the above copyright |
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
extension Collection { | |
func eachConsecutive(_ size: Int) -> Array<SubSequence> { | |
let droppedIndices = indices.dropFirst(size - 1) | |
return zip(indices, droppedIndices) | |
.map { return self[$0...$1] } | |
} | |
} |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,