andymatuschak

A composable pattern for pure state machines with effects

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,

oisdk

import Foundation

protocol Currency { static var sign: String { get } }
enum GBP: Currency { static let sign = "£" }
enum EUR: Currency { static let sign = "€" }
enum USD: Currency { static let sign = "$" }

protocol _Money {
  associatedtype C: Currency
  var amount: NSDecimalNumber { get }

krzyzanowskim

import Cocoa

// for-in
func checkForIn(array: [Int], dict: [Int: String]) {
    for num in array where dict[num] != nil {
        num
    }
}

checkForIn([1,2,3,4], dict: [1:"one", 2:"two"])

klaas

// Swift version of: https://gist.github.com/smileyborg/a5d1355773ad2ba6bb1e

public enum ViewOrientation {
	case Portrait
	case Landscape
}

extension UIView {
	public class func viewOrientationForSize(size:CGSize) -> ViewOrientation {
		return (size.width > size.height) ? .Landscape : .Portrait

drewcrawford

This, is actually the wrong conclusion. The entire purpose of the “inner class” is to provide value semantics while maintaining effeciency of implementation.

Is that an opinion? Or was there a meeting when the "entire purpose" of inner classes was established and I wasn't invited? Sure, they can be used for efficiency, but they can also be used for other purposes, including inner mutation.

Just for starters, Mike Ash seems to have uncovered that inner classes are used inside the standard library to provide destructors:

Destruction can be solved by using a class, which provides deinit. The pointer can be destroyed there. class doesn't have value semantics, but we can solve this by using class for the implementation of the struct, and exposing the struct as the external interface to the array.

So to say that the "entire purpose" of inner classes is efficiency is I think plainly false; they are used for many reasons. E

mackuba

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.

OS X El Capitan

http://www.apple.com/osx/elcapitan-preview/

• split view - two apps side by side on full screen

nicklockwood

Thoughts on Swift 2 Errors

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:

chriseidhof

//
//  AppDelegate.swift
//  TypedTableViewControllers
//
//  Created by Chris Eidhof on 23/03/15.
//  Copyright (c) 2015 Unsigned Integer. All rights reserved.
//

import UIKit

ColinEberhardt

// meet Stringy - a simple string type with a fluent interface
struct Stringy {
  let content: String
  
  init(_ content: String) {
    self.content = content
  }
  
  func append(appendage: Stringy) -> Stringy {

smileyborg

//
//  UIView+Orientation.h
//

#import <UIKit/UIKit.h>

// These macros should only be used if you MUST know the interface orientation for the device itself, for example when displaying a new UIWindow.
// This should be very rare; generally you should only look at the immediate parent view's size (or "view orientation" using the category below).
#define StatusBarOrientationIsPortrait      UIInterfaceOrientationIsPortrait([[UIApplication sharedApplication] statusBarOrientation])
#define StatusBarOrientationIsLandscape     UIInterfaceOrientationIsLandscape([[UIApplication sharedApplication] statusBarOrientation])