Most of these guidelines are to match Apple's documentation and community-accepted best practices. Some are derived some personal preference. This document aims to set a standard way of doing things so everyone can do things the same way. If there is something you are not particularly fond of, it is encouraged to do it anyway to be consistent with everyone else.
This document is mainly targeted toward iOS development, but definitely applies to Mac as well.
NSString *foo = @"bar";
| // Define your table view's sections | |
| typedef enum { | |
| kTitleSection = 0, | |
| kGoalSection, | |
| kNumberOfSections | |
| } NESTemplateEditTableSections; | |
| // Make configuration arrays indexed against table sections. | |
| // It's safe to reorder the original enum! | |
| static NSString * const kCellIdentifiers[kNumberOfSections] = { |
| #!/usr/bin/env ruby | |
| # This pre-commit hook will prevent any commit to forbidden branches | |
| # (by default, "staging" and "production"). | |
| # Put this file in your local repo, in the .git/hooks folder | |
| # and make sure it is executable. | |
| # The name of the file *must* be "pre-commit" for Git to pick it up. | |
| FORBIDDEN_BRANCHES = ["staging", "production"] |
| // this is a playground | |
| protocol Nat { | |
| class func construct() -> Self | |
| class func value() -> Int | |
| } | |
| struct Z : Nat { | |
| static func construct() -> Z { | |
| return Z() | |
| } |
| // ~(P ∨ Q) = ~P ∧ ~Q | |
| enum Nothing {} | |
| struct Not <A> { | |
| let not: A -> Nothing | |
| init (_ not: A -> Nothing) { self.not = not } | |
| } | |
| struct And <A, B> { |
| /* | |
| * We've defined "traits" by which we can type an integer that are characteristic of its value. | |
| * These traits can even be subtraits of other traits (like both positive and negative being nonzero). | |
| * | |
| * We can use these traits in the type signatures of functions to indicate what trait will be returned | |
| * as a function of the passed-in traits. | |
| * | |
| * Even cooler, we can specify properties of the traits such that we can runtime-verify the correctness | |
| * of these labels (in case a function was improperly annotated, for example). | |
| */ |
A primer/refresher on the category theory concepts that most commonly crop up in conversations about Scala or FP. (Because it's embarassing when I forget this stuff!)
I'll be assuming Scalaz imports in code samples, and some of the code may be pseudo-Scala.
A functor is something that supports map.
(Source: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html)
The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus fair, with just this short blurb in the list of goals:
Complete generics: Generics are used pervasively in a number of Swift libraries, especially the standard library. However, there are a number of generics features the standard library requires to fully realize its vision, including recursive protocol constraints, the ability to make a constrained extension conform to a new protocol (i.e., an array of Equatable elements is Equatable), and so on. Swift 3.0 should provide those generics features needed by the standard library, because they affect the standard library's ABI.
This message expands upon the notion of “completing generics”. It is not a plan for Swift 3, nor an official core team communication, but it collects the results of numerous discussions among the core team and Swift developers, both of the compiler an
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,
| // MARK: Equatable | |
| func ==<T>(lhs: TerminatingNode<T>, rhs: TerminatingNode<T>) -> Bool { | |
| return lhs.value == rhs.value | |
| } | |
| func ==<T, U>(lhs: ListNode<T, U>, rhs: ListNode<T, U>) -> Bool { | |
| return lhs.value == rhs.value && lhs.next == rhs.next | |
| } |
