-
Notifications
You must be signed in to change notification settings - Fork 184
BrightFutures needs a 1.0 release #12
Comments
👍 On making Queue.main the default callback thread. I find that most of my callbacks make changes to the UI. |
@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? |
If you want to try out the 'adaptive callback queue' behavior, see https://github.com/Thomvis/BrightFutures/tree/1eebc34c42cbcd2569e27ce9b2355aa71d5d35dc. |
"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. |
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 |
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'.
} |
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. |
The problem I see is that throughout the BrightFutures framework, Too bad extensions of generics in other modules are not supported yet; that would be a great solution. |
We might be able to solve this by creating a FutureType protocol and return Self from those methods. Interesting. |
@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. |
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 Pausing, cancellation & progress will not be part of the core 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 |
Thanks to @tmu, master is compatible with Swift 1.1 again. There's a |
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. |
@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. |
@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. |
@bejar37 I would say that is quite clear from the docs that the closure handed to I haven't heard yet from people that are having issues with this, so I'd vote for keeping the |
@Thomvis how can I help with ObjC support? What's been done to date? |
@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! |
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. |
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. |
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. |
I agree. I don't think Objective-C support should hold BrightFutures from reaching 1.0.0 release. |
🎉 BrightFutures 1.0.0 is out 🎉 Thanks all for your patience and help! |
Congratultions an thank you! I really like them and do use them. Jaromir
|
Congrats! This is a great library and I love using it. |
Great work, @Thomvis! |
Yes very nice work! |
This issue is created to track the progress towards releasing a 1.0 version. Please chime in if you have any feedback or requests!
TODO:
Future.succeeded(..)
andf.succeeded()
(same goes forfailed
) is confusing.f.completed({}, {})
(and in a lesser way inf.succeeded { }
andf.failed { }
adds enough value to justify its existence.Future
andTaskResult
havesucceeded
,failed
andcompleted
(/handle
) methods, which seems duplicate.TaskResultValueWrapper
. Luckily, it is almost never exposed through public API.FutureUtils
functions from Scala have been ported over yetFuture
should be a pure functional future (two states: pending or complete), more like a 'task' (pending, complete, cancelled, succeeded, failed) or somewhere in betweenPostponed until after 1.0:
The methods inFutureUtils
should work on anySequenceType
, not only onArray
Move helper classes (Queue, Semaphore, ExecutionContext) to a separate frameworkA logo?Add Objective-C supportThe text was updated successfully, but these errors were encountered: