matttthompson

And to be clear—these are all existing sample apps for open source Objective-C projects. The creator of this site does not appear to have done anything but gathered these up into zip files. The complete lack of attribution is misleading.

I have no illusions about the amount of effort and investment necessary to change technology stacks. Carbon was only officially deprecated in OS X 10.8. To speak of the death of technology is only to acknowledge that it is mortal.

My claim isn't that everything will be rewritten in Swift—far from it. Instead, the article is an exploration of what it would mean for Swift to evolve beyond the constraints of Objective-C & Cocoa interoperability, and how that may occur as Swift gains momentum.

I appreciate your feedback, but I think you're reading an entirely different argument than what is presented in the article. It's not that everything is going to be rewritten in Swift (I'm not sure where you got that idea). Rather, the article is an exploration of what Swift without Obj-C & Cocoa could be, and under what circumstances that might become a reality.

If Swift doesn't have to accommodate Objective-C as it currently does, it's reasonable to assume that system frameworks will be designed and built in ways that make the most of Swift's language features, just as Cocoa currently does with Objective-C.

I don't really see much need for it. Others are welcome to create such an integration, but I probably won't do so myself.

You make some good points, and I agree to caution against names that bear no semantic relationship with their purpose. My justification of Alamofire is that it reflects the history of the project, which traces back from AFNetworking to Gowalla (formerly Alamofire, Inc.), the product for which it was originally developed.

> Was there any reason why you chose callbacks over a Promise-like pattern for the async responses?

Deeply-nested networking callbacks are a code smell, and I find that promises often do more harm by hiding those smells—or worse, obscuring the flow itself. In practice, Alamofire is mostly going to be single or at most nested two levels deep anyway.

Yes, that's correct.

The short answer: Use the version of `request` that takes a `URLRequestConvertible`, and specify the header fields in that.

The long answer: Custom headers on a per-request basis are a bit of a red herring, from an API design perspective. In reality, most use cases boil down to one of three, which are taken care of in other ways:

- Default headers, such as `User-Agent`, are specified in `NSURLSessionConfiguration -HTTPAdditionalHeaders`. - `Authorization` headers, which are handled by `NSURLCredential` and `NSURLAuthenticationChallenge`. - `Content-Type` headers, which are handled by `ParameterEncoding`.

This is why Alamofire is designed the way it is.

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

Author of the article here. Let me know if you have any questions or feedback.