/// | World |
/// |------------------------------------------|
/// | Module A | Module B | Module C | Module D|
- World is a module
- World is aware of all modules.
- Modules aren't aware of World.
/// | World |
/// |------------------------------------------|
/// | Module A | Module B | Module C | Module D|
struct Contact: Decodable, CustomStringConvertible { | |
var id: String | |
@NestedKey | |
var firstname: String | |
@NestedKey | |
var lastname: String | |
@NestedKey | |
var address: String | |
enum CodingKeys: String, NestableCodingKey { |
xccov(1) xccov(1) | |
NAME | |
xccov - view Xcode coverage data in human-readable or machine-parseable format. | |
SYNOPSIS | |
xccov view [--only-targets | --files-for-target target_name | --functions-for-file name_or_path] |
// 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) |
Purpose of this list is to gather a source of information on how many people are working on iOS application.
I often wonder how many people are behind Facebook's app or Twitter's. If you're as curious as me, please share and please add apps 😉.
*
- it's a rumoured value only. Needs confirmation from someone inside the company.
I hereby claim:
To claim this, I am signing this object:
##Adding Swift Build System
Preferences > Browse Packages...
Swift.sublime-build
inside Packages
directory.Swift.sublime-build
file.{
"shell_cmd": "xcrun swift $file",
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: