Author: Chris Lattner
- 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.
#Ruby Programming Language
#Chapter 6 Methods, Procs, Lambdas, and Closures
##Defining methods
- to define method use
def
followed by method name - put method parameters in round brackets ()
- Abnormal method termination is when method raises exception
- If method terminates normally then last expression evaluated in method body will be method invocation value
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,
COMPACT WIDTH (stacked view) | |
- 320 x 568 pt | |
-> iPhone 5, 5s | |
- 320 x 768 pt | |
-> iPad 9.7" Split Landscape 2/3 right | |
- 320 x 834 pt | |
-> iPad 10.5" Split Landscape 2/3 right | |
- 320 x 1024 pt | |
-> iPad 9.7" Split Portrait right |
// | |
// AppDelegate.m | |
// NanoCompanion | |
// | |
// Created by Steven Troughton-Smith on 13/01/2015. | |
// Copyright (c) 2015 High Caffeine Content. All rights reserved. | |
// | |
#import "AppDelegate.h" |
// See http://nshipster.com/key-value-observing/ | |
// Put this code a common utilities header, and use it to have the compiler help check correctness of key paths. | |
// Uses macro stringification to create an Obj-C string literal, plus validation code that the compiler optimizes out. | |
@interface NSObject (KeyPathFakeCategoryForCompilerWarnings) | |
+ (instancetype)__fake_method_for_compiler_warnings__; | |
- (instancetype)__fake_method_for_compiler_warnings__; | |
@end | |
/*! Returns a string for the given keypath, but causes a compiler warning if the keypath is not defined on \c self. |
#!/usr/bin/env sh | |
open "tel://$*" |
enum Either<A, B> { | |
case Left(A) | |
case Right(B) | |
} | |
func isLeft<A,B>(it : Either<A,B>) -> Bool { | |
switch it { case .Left: return true; case .Right: return false } | |
} | |
func isRight<A,B>(it : Either<A,B>) -> Bool { |
- (void)viewWillAppear:(BOOL)animated | |
{ | |
[super viewWillAppear:animated]; | |
NSIndexPath *selectedRowIndexPath = [self.tableView indexPathForSelectedRow]; | |
if (selectedRowIndexPath) { | |
[self.tableView deselectRowAtIndexPath:selectedRowIndexPath animated:YES]; | |
[[self transitionCoordinator] notifyWhenInteractionEndsUsingBlock:^(id<UIViewControllerTransitionCoordinatorContext> context) { | |
if ([context isCancelled]) { | |
[self.tableView selectRowAtIndexPath:selectedRowIndexPath animated:NO scrollPosition:UITableViewScrollPositionNone]; |