BrightFutures needs a 1.0 release about brightfutures HOT 28 CLOSED

👍 On making Queue.main the default callback thread. I find that most of my callbacks make changes to the UI.

from brightfutures.

@wvteijlingen thanks for your input. I'm also in favor of the main thread but I have this other idea: if the callback block is registered on the main thread: perform it on the main thread, else: perform it on a random background thread (global queue). What do you think?

from brightfutures.

If you want to try out the 'adaptive callback queue' behavior, see https://github.com/Thomvis/BrightFutures/tree/1eebc34c42cbcd2569e27ce9b2355aa71d5d35dc.

from brightfutures.

"Adaptive callback queue", sounds nice! I think this is a good solution, it takes the hassle out of specifying a queue by automating it, but still allows you to be more specific if needed.

from brightfutures.

Added "Decide whether Future should be a pure functional future (two states: pending or complete), more like a 'task' (pending, complete, cancelled, succeeded, failed) or somewhere in between" to the list of items

from brightfutures.

Regarding that, it would be nice if we could subclass Future/Task and add more types of 'results'. Then we could use it like this, for example when communicating with an API:

someFuture.onSuccess {
  // Success
}.onAPIFailure { error in
  // Error returned from the server. E.g. 'internal server error'.
}.onFailure { error in
  // Error returned from the framework. E.g. 'no network connection'.
}

from brightfutures.

I agree that would be nice. We could enable this by subclassing Future (e.g. APIFuture) and add additional callbacks, which could be tiny wrappers around the 'native' callbacks.

from brightfutures.

The problem I see is that throughout the BrightFutures framework, Future<T> types are returned. Subclassing does't really work because for example onSuccess returns the base Future<T> type.

Too bad extensions of generics in other modules are not supported yet; that would be a great solution.

from brightfutures.

We might be able to solve this by creating a FutureType protocol and return Self from those methods. Interesting.

from brightfutures.

@wvteijlingen If you still would like the functionality that you described in your earlier comments, please file a separate issue to make sure it doesn't get lost.

from brightfutures.

I just marked the sub-task "Decide whether Future should be a pure functional future (two states: pending or complete), more like a 'task' (pending, complete, cancelled, succeeded, failed) or somewhere in between" as completed. I think the Future type as it is now is a good balance of a pure functional future and a practical one.

Pausing, cancellation & progress will not be part of the core BrightFutures Future, but I've started working on a wrapper around NSProgress (Thomvis/GoodProgress) that offers such functionality and envision a third library that combines GoodProgress and BrightFutures.

from brightfutures.

I think you (we) should keep BrightFutures 1.0 / master compatible with Swift 1.1, because apps compiled with XCode 6.3 Beta / Swift 1.2 can't be submitted to AppStore. Only official XCode builds + XCode GM can be used for App Store submissions and those are likely available around April-June.

If you want to forget Swift 1.1 already and keep BrightFutures 1.0 compatible only with Swift 1.2 , I can take a responsibility of Swift 1.1 fork and backport some important production code features like InvalidationTokens to it.

Related issue is #31

from brightfutures.

Thanks to @tmu, master is compatible with Swift 1.1 again. There's a swift1.2 branch that works well for Swift 1.2. When Swift 1.2 is released to the public, master will switch to Swift 1.2 and, if needed, a Swift 1.1 compatible fork will be created.

from brightfutures.

Sorry for just dropping in on this, looks like a great library! Was there a resolution on the "adaptive callback" queue issue? I definitely think it'll make BrightFutures a lot nicer for us app developers.

from brightfutures.

@bejar37 Yes, the adaptive callback queue has been implemented for a while now. You can read about it in the readme: https://github.com/Thomvis/BrightFutures#default-threading-model.

from brightfutures.

@Thomvis, ah, I missed that in the docs. I was referring to this:

future {
//This is not the main thread, don't do anything that requires being on the main thread
}

I'm not sure how surprised people would be by this behavior, but I think that in iOS this is somewhat of a liability.

I understand that it makes the interface less clean, but the right thing to do here might be to require an explicit execution context (perhaps by passing in an enum member?) when a future is explicitly created like this.

from brightfutures.

@bejar37 I would say that is quite clear from the docs that the closure handed to future is executed asynchronously. I also think it does not make much sense to execute a future's closure on the main thread.

I haven't heard yet from people that are having issues with this, so I'd vote for keeping the future function as-is, i.e. with an optional execution context.

from brightfutures.

@Thomvis how can I help with ObjC support? What's been done to date?

from brightfutures.

@tonyarnold ObjC support is pretty far already (see #27). I think it is still missing some tests, a FutureUtils equivalent, the invalidation tokens and that's it. If you want to have a look at any of those missing pieces, that would be helpful. Let's discuss this in the PR. Thanks!

from brightfutures.

I've updated the list to reflect the items that I'd like to postpone until after 1.0. Objective-C support is nearly done so I'm hoping 1.0 can be released pretty soon.

from brightfutures.

I'm thinking about stopping Objective-C support development (at least for 1.0). I have to admit that the reason is a bit selfish: I have been working in Swift more and more lately.

Let me know if anybody was looking forward to this. Otherwise I'll go ahead and clear that of the list of things blocking a 1.0.0 release.

from brightfutures.

I don't think that's selfish — just a reality of running a project with a single developer contributing. I was keen on Objective-C support, but it can definitely wait until there's more time. It shouldn't hold up 1.0.

from brightfutures.

I agree. I don't think Objective-C support should hold BrightFutures from reaching 1.0.0 release.

from brightfutures.

🎉 BrightFutures 1.0.0 is out 🎉

Thanks all for your patience and help!

from brightfutures.

Congratultions an thank you!

I really like them and do use them.

Jaromir

On 5. 5. 2015, at 11:48, Thomas Visser [email protected] wrote:

🎉 BrightFutures 1.0.0 is out 🎉

Thanks all for your patience and help!

—
Reply to this email directly or view it on GitHub.

from brightfutures.

Congrats! This is a great library and I love using it.

from brightfutures.

Great work, @Thomvis!

from brightfutures.

Yes very nice work!

from brightfutures.