Alamofire: Get rid of custom Result type and use Rob Rix's Result framework

[klundberg]

I'm using the Result framework here: https://github.com/antitypical/Result and it's conflicting with the Result type in Alamofire 2.0 in my files where I import both. The Alamofire Result is pretty barebones and could probably be completely replaced with the dedicated Result framework, and extended for any convenience methods needed.

[cnoon]

We will not be adding a dependency to the core Alamofire framework. Adding a dependency has many risks and greatly increases complexity for those adopting it. The fact that the two Result types collide is something you can easily resolve on your end by adding the framework namespace.

The Alamofire Result type does not contain all the same complexity due to the fact that it does not need it. If you feel there are certain cases that our current implementation does not handle properly or as well as it could, then please open a pull request with a good explanation of why the additional logic is necessary, and we'll take a look.

[marcelofabri]

The problem is that using the framework namespace don't work when the framework name is the same as another type. There's more info on this issue: https://github.com/antitypical/Result/issues/77

[klundberg]

No problem, thanks for the explanation. My request stemmed from the fact that since the dedicated result framework's module name is also result, the compiler gets confused when importing both and won't let me reference the other one. I have found a workaround that is suitable though so that I can keep using both Alamofire and result.

Thanks for the response!

[cnoon]

Looks like there are radars filed @marcelofabri and there's also an acceptable workaround to the problem. While I understand it's not as convenient as you would like, I don't think it's appropriate for us to rename our classes due to other third party library collisions.

[Rupert-RR]

I appreciate that it's your call, but I really don't see a disadvantage to using the existing framework — yes it introduces a dependency, but the whole point of having Alamofire as a framework generally is that it is a dependency which it is easy to add to a project.

And yes, the Result framework is a little more complicated than the Result type provided in Alamofire... but not much more — a bit over twice the number of lines of code used for the Result object (already not much) in Alamofire and it includes lots of nice convenience methods for handling / chaining on it. The kind of thing that would be useful when using Alamofire to better handle errors. Using a Result object is definitely a good idea, but you would either expect to make one that rivals existing ones so that it could be used throughout a project, or use an existing one.

[cnoon]

@Rupert-RR it is a very unwise decision to couple to any dependency that you do not control for large open-source projects. Anyone that has been responsible for such a library knows exactly what I mean by this. As soon as you add the dependency, you are forever bound by that dependency if there are new Swift beta releases, bugs, changes that don't conform to semver, etc. This is not something we're interested in exposing ourselves or the community to.

Additionally, the Result type provided in Alamofire is tailored specifically to Alamofire use cases. It is not intended to be used as a solve all Result type outside of Alamofire APIs. It also includes an additional data associated value in the .Failure condition which the antitypical/Result library doesn't support.

Hopefully that clears up any confusion.

[Rupert-RR]

@cnoon I can understand that you don't want to have problems because of breaking Swift updates but hopefully they are behind us now (and in any event, they would entail changes to the Alamofire library too, and the Result library is likely to be faster to react because they seem to be on the cusp for the latest versions and it is also a much smaller library). Result also uses semantic versioning for releases which should ensure backwards compatibility.

Although I can understand the worries with adding dependencies (it takes some of the control out of your hands and potentially involves extra work ensuring compatibility) I would argue that this is what open source is about. I know that many libraries depend on AFNetworking (hopefully they'll all upgrade to Alamofire soon), often as a non-explicit dependency, but by your argument they should not because of all the problems dependencies bring. But generally they do this because the core part of their library is about something other than networking, and there is no point in re-inventing the wheel. I would say that the Result object is not a core part of Alamofire, but is part of a much wider programming paradigm and as such, you might as well use it. To people using Alamofire via CocoaPods or Carthage this will be transparent, since this is what they are using a dependency manager for (and I suspect that most people are integrating Alamofire in this way). Nothing stops you changing this dependency later (versioning should ensure that people have the appropriate version).

With regards the special capability of the Alamofire Result object, to include a data object with the failure, I would say that this data should be part of the error object itself (what the old userInfo would carry, and easy to add to any object that conforms to ErrorType).

You say that the Result object is not intended to be used much outside of Alamofire, but as part of the method results for the most important parts of the framework it is obviously going to be used, and while we can always map one type of object to another, there seems little point in forcing those extra steps. I would say that Alamofire is one of the best examples of a framework where you would expect to be using a generic Result object because networking requests are a very good use case for them.

Sorry for the length of the reply, and I respect whatever decision is made, but in terms of arguing the case, I do feel strongly that it is worth using other libraries as opposed to re-inventing what already exists. The whole point of using dependency managers is that this is now a painless exercise.

[cnoon]

Let's agree to disagree @Rupert-RR. I'm not interested in discussing this further.