I really like the Result approach and I would like...

# kotlin-fuel

[Mark Gilchrist]

I really like the Result approach and I would like to use it, if however you all feel that this would not be an advantage I am happy not to do another pr

[Lucas]

I agree that an API that returns Result is a good idea, too. But to avoid confusion, it may be a good idea to refactor the current API, which may cause braking changes.

[Lucas]

If that's acceptable I think it may be a good addition.

[Mark Gilchrist]

would you be happy with the following steps

[Mark Gilchrist]

1) create the functions with names you think they should have

[Mark Gilchrist]

2) mark the current funtions as depicrated with a @ReplaceWith naming the new functions

[Mark Gilchrist]

3) we give people 6 months to change to the new ones

[Mark Gilchrist]

4) add the Result based functions

[Mark Gilchrist]

5) after a period of agreed time we then remove the old ones,

[Mark Gilchrist]

noones code breaks and 🍻

[Mark Gilchrist]

?

[Lucas]

Yes, deprecation is a solution.

[Lucas]

Have you made a prototype? Maybe we can find a workaround. 🙂

[Mark Gilchrist]

shall do what I have in a branch and you can look at it before I raise a pr?

[Mark Gilchrist]

I am sure that I will survive if we decide that my idea is not a good one going forward?

[Mark Gilchrist]

https://github.com/kittinunf/Fuel/compare/master...markGilchrist:Add_Result_and_object_Implementations?expand=1

[Lucas]

It seems good to me. Also after working on PR 373 having an API returning Result makes much more sense. I hope it gets accept by the maintainers.

[Lucas]

Thank you for proposing this and making the prototype!

[Mark Gilchrist]

I will give it a much bigger unit test coverage and JDocs before I do that

[kittinunf]

Hey! Sorry I have been logged in this workspack for a while (haha I should be ashamed of myself)