nicklockwood

// Swift's untyped errors are a goddam PiTA. Here's the pattern I use to try to work around this.
// The goal is basically to try to guarantee that every throwing function in the app throws an
// ApplicationError instead of some unknown error type. We can't actually enforce this statically
// But by following this convention we can simplify error handling

enum ApplicationError: Error, CustomStringConvertible {
    
  // These are application-specific errors that may need special treatment
  case specificError1
  case specificError2(SomeType)

nicklockwood

enum ValueError: Error {
  case notFound
  case typeMismatch
}

struct PropertyError: Error {
  let name: String
  let error: ValueError
}

nicklockwood

A very basic JSON parser, written in [new language]. Only supports String, Int and Array so far.

json := "[42, \"hello\", [\"good\", \"bye\"]]"

JSON = String|Int|[JSON] // TODO: true, false, null, object

skipSpace(json: String) String {
    input := json
    while input.first == " " {

nicklockwood

App Store Wishlist

Some changes (besides the subscriptions features added recently) that I'd like to see in the App Store.

NOTE: This is in no way an attempt at an exhaustive list of all things wrong with the App Store. The focus of this list is mostly around improvements to make it easier for developers to make money from their apps without annoying customers. Other problems such as the broken review process, or inability to contact customers directly, etc. are out of scope.

• Time or feature-limited demos with IAP to get full version. You could argue that this is already possible, but time-limits are against App Store policy, and apps that do it appear in the "Free" section with "Offers IAP" messaging, making them indistinguishable from pay-to-win junk. These would appear under "Paid" (and/or in their own category) and would have clear messaging that this was a free trial of a paid app. There would be other benefits too: You'd be able to gift a copy of the full app to someone witho

nicklockwood

@interface AnimatedContentsLayer: CALayer

@property (nonatomic, assign) CGSize animatedSize;

@end


@implementation AnimatedContentsLayer

@dynamic animatedSize;

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:

nicklockwood

var React = require('react-native');
var { requireNativeComponent } = React;

module.exports = requireNativeComponent('Carousel', null);

nicklockwood

import Accelerate

struct Matrix4 {
    var m11: Float
    var m12: Float
    var m13: Float
    var m14: Float
    var m21: Float
    var m22: Float
    var m23: Float

nicklockwood

- (void)writeObject:(id)object toFile:(NSString *)file withPassword:(NSString *)password
{
    NSData *data = [FastCoder dataWithRootObject:object];
    CryptoArchive *archive = [[CryptoArchive alloc] initWithRootObject:data password:password];
    data = [FastCoder dataWithRootObject:archive];
    [data writeToFile:file atomically:YES];
}

- (id)readObjectFromFile:(NSString *)file withPassword:(NSString *)password
{

nicklockwood

//here is an array factory method

@interface Foo: NSObject

@end

@implementation Foo

+ (NSArray *)newArray
{