How would the explicit case of success/fail for an API response compare to the Promise pattern?
The power of Result types in Swift
41–50 of 77 posts
Re: The power of Result types in Swift
#42How would the explicit case of success/fail for an API response compare to the Promise pattern?
Seems perhaps the Promise pattern is more conducive for composition, aggregation, etc of multiple asyncs?
Or are they just two different problem domains?
Re: The power of Result types in Swift
#43Earlier quoted context omitted.
C is in no way typeless. Furthermore, i would expect a well behaved dev to avoid c at all cost.
Well, this article is about Result types in Swift, and my point is, I think this kind of thing is overkill. It tends to make the learning curve for a new programmer steeper because there's all these extra bells and whistles provided by the language that have to be learnt before you can get going, and then you have sample code and tutorials and so on. Learning and using C was and is a lot simpler than say Swift.
This is completely true. However, after having learned both sides, I certainly appreciate the compiler’s help. I think it’s the classic tradeoff between specialization and accessability at play here.
Re: The power of Result types in Swift
#44The reason I started using this pattern is one I didn’t see the article mention: With legacy style result callbacks, you’ll have both an optional value and an optional error returned - this corresponds to four possible states. If I’m using an API returning this, I have to think about two cases which probably won’t happen (neither an error or value, or both an error and a value). I’d like to think the API I’m using wo…
To nitpick, the “both error and data” can happen, for example when the connection drops in the middle of a large response. Probably doesn’t change anything, but it’s good to know, maybe so that you don’t trap on an unexpected combination.
Re: The power of Result types in Swift
#45The tricky part of this approach comes when you extend it. Let's say we have two functions and we'd like to combine them and return a third. typealias Handler1 = (Result -> Void) typealias Handler2 = (Result -> Void) func load(addr: Address, then handler: @escaping Handler1) { ... } func lookup(name: string, then handler: @escaping Handler2) { ... } // What would the type of Handler3 be? func loadDefault(then handler…
You can improve that code by having a single error type. Either by returning the same error from both handlers or having an error sum type which contains both errors. You probably don't really care about the exact error that can be thrown by either handler, you just need enough information to display a sensible message to the user. NSError may be just enough for that purpose! After doing that, the type of Handler3 ca…
> the type of Handler3 can be had as Result, NSError>,
The combination of data and lookup is more like data(lookup(default)), which in haskell (assuming we could encode the error type neatly):
load => You probably don't really care about the exact error that can be thrown by either handler, you just need enough information to display a sensible message to the user.
Please consider looking for the part of the article we're discussing where it says, "However, adding that extra type information to our result type does have some nice benefits - for example, it lets us specifically handle all possible errors at the call site, like this"
Ultimately we'd like to get to where the compiler can do at least a rudimentary totality check on the error handler.
P.S., I know my prose is rambling and my code is overly verbose, but please consider how it makes me feel when you give me suggestions I myself discussed in the prior post.
Re: The power of Result types in Swift
#46It seems like a major legacy of practical experience with FP in the 200x and 201x years is going to be result types.
Also, the idea of mapping and folding, which is now everywhere, and is not limited to traditional collections. (Likely applicatives will take another decade to go mainstream.)
The 4th generic added to Go will be our memorial.
Erring[ResultType]Re: The power of Result types in Swift
#47Earlier quoted context omitted.
Well, this article is about Result types in Swift, and my point is, I think this kind of thing is overkill. It tends to make the learning curve for a new programmer steeper because there's all these extra bells and whistles provided by the language that have to be learnt before you can get going, and then you have sample code and tutorials and so on. Learning and using C was and is a lot simpler than say Swift.
This is completely true. However, after having learned both sides, I certainly appreciate the compiler’s help. I think it’s the classic tradeoff between specialization and accessability at play here.
I think the designers (Apple) have targeted a certain class of apps with Swift, XCode and the underlying libraries (Cocoa). A majority of their existing developer base will likely benefit from what they've done. But from the point of view of new developers and someone who's just trying to use the hardware in an effective way, this is not a step forward.
Re: The power of Result types in Swift
#48Earlier quoted context omitted.
C is in no way typeless. Furthermore, i would expect a well behaved dev to avoid c at all cost.
Well, this article is about Result types in Swift, and my point is, I think this kind of thing is overkill. It tends to make the learning curve for a new programmer steeper because there's all these extra bells and whistles provided by the language that have to be learnt before you can get going, and then you have sample code and tutorials and so on. Learning and using C was and is a lot simpler than say Swift.
I keep hearing for about 30 years now, how writing correct code in C is just a matter of being good.
Re: The power of Result types in Swift
#49I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/ . In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. N…
What I found interesting is that if you have a pipe/filter architectural style, your happy path stays completely free of error handling, because when a filter doesn't have a good result, it just doesn't pass any data to the next filter in line. Done! You can then centralize the error handling by having a "stderr"-like output on your filters. When you have a call/return architectural style, you need to return somethin…
>> if you have pipes/filters, you stay free of error handling: when a filter doesn't have a result, it just doesn't pass any data to the next filter in line.
That is an important root insight. It also applies to for loops, and could apply to switch statements
switch result { case something: break case none: error: empty: default: //? }
Re: The power of Result types in Swift
#50I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/ . In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. N…
It's not exactly the same as railway programming as in Swift it's typically not used to connect functions together but rather to replace separate callbacks with one "result" function and to hard type certain results. One typical case in Objective-C style API's would be: - (void)fetchData whenDone finished: [a block] ifFails failed: [another block] Or: - (void)fetchData whenDone finished: [a block that has nullable Da…
> web API driven iOS and macOS applications) simply don't lead to these huge chains of functions
I agree you don't see them collected together, as a rule, but if you follow Results like this in those domains you see them being used multiple times on the backend before being yeilded to the frontend for further handling, resulting in chains that are just spread out a little bit more.
Personally I've started exposing them through JSON at the API level to further extend the systems explicitness and idempotency.