Use robrix/Box instead of own Box type

[nvh]

When using BrightFutures together with other libraries that implement a Box to work around the enum limitations, it can be confusing to have multiple Box types in your codebase. I would suggest using robrix/Box, since that seems to become the standard micro-framework to use for solving this problem.

[Thomvis]

I think we should consider this together with using https://github.com/antitypical/Result.

It is counter productive for every library to have its own Box/Result/Queue/etc. implementation. On the other side, by adding dependencies (BrightFutures currently has none), the library may become less accessible.

I don't know what the right thing to do is yet and would love to hear what other people think.

[nvh]

I totally agree. You want as few dependencies as possible (preferably none), but for people not using other frameworks for Box/Result, etc, it's so few code that I can't see any reasonable complaints of adding those dependencies. For people that are using Box and Result in other places, it's nice to have one implementation that most libraries reference, and for now my bet is on @robrix's frameworks.

Today I wrote a conversion between BrightFutures.Box and Box.Box and BrightFutures.Result and Result.Result, and it felt kind of weird and something I'd rather not handle with.

BTW: The only dependency would be Result, because that has a dependency on Box itself.

[robrix]

FWIW, we removed Result’s dependency on Box.framework, but decided to re-add it to ease its integration into ReactiveCocoa 3.0 (and to recover some lost expressiveness around pattern matching).

My personal take is that the broader community will become more comfortable with dependencies primarily by their use; and that µframeworks provide an optimal balance since quantity of dependencies does not pose a difficulty to maintenance, while surface area, which they minimize, does.

I think this is a good direction for BrightFutures to move in; and I’m glad to have learned of its existence!

[zenkimoto]

👍 +1 on using https://github.com/antitypical/Result

I was thinking of mentioning this too.

[larslockefeer]

If we do this, could we then also have Future<Value, Error> instead of Future<Value, NSError>? This would allow us to use context-specific error types without subclassing NSError, for more semantical code.

[Thomvis]

@larslockefeer I agree! I will merge #49 and then try to extend the approach with the custom error type

[Thomvis]

BrightFutures 2.0 has been released, which resolves this issue.