BrightFutures 5 about brightfutures HOT 21 CLOSED

I have a suggestion. The error handling could be more swift 2.0 style. Similar to what pomisekit does. Using throw instead of passing it in the second generic argument.

from brightfutures.

It would be nice to be able to specify a default execution context for an entire target. Currently we'd like to use asynchronous dispatch within our app, but be able to set immediate execution context as the default within the test target, so we don't need to waitForExpectation in every test.

Our way around this for now is to pass the execution context in to our consumers at init, but a global way (which we could use in XCTest's setUp method) would be great.

from brightfutures.

@matthew-healy This is something I've also been thinking about in the context of making BF more flexible to suit the needs on different platforms with different concurrency models.

The easy way to do this would be to make a global ThreadingModel that you can configure. The big issue with this however is that anyone can change the behavior of all futures, e.g. any included third party library can change the behavior of futures you create. If we're making this just for testability, this isn't really an issue though.

A second approach would be to have a FutureFactory (I've been doing some Java lately 😉), but I don't really like the idea of that.

Any other suggestions?

from brightfutures.

This would be an awesome feature to make ThreadingModel globally configurable. I actually have been thinking about adding it myself.

from brightfutures.

Initially I was entirely for the idea of a global, configurable ThreadingModel, but I think I agree that this is an unsafe approach. My concern with this is less about the behaviour of third party libraries, and more about different developers on the same team. It would be very easy for someone to set everything to synchronous rather than work out how contexts should really be used.

In thinking about mitigating this possibility, I came up with the following...

• Introduce a protocol along these lines:

protocol ThreadingModel {
    var context: ExecutionContext { get }
}

• Define an enum DefaultThreadingModel along the following lines:

enum DefaultThreadingModel: ThreadingModel {
    case .Asynchronous
    case .Synchronous

    var context: ExecutionContext {
        switch self {
        case .Asynchronous:
            return toContext(NSThread.isMainThread() ? Queue.main : Queue.global)
        case .Synchronous:
            return { task in task() }
        }
    }
}

• Finally, have a globally accessible var which can be set by the user, but only to one of the predefined options in the enum above, and so when no context is passed in, we can fall back to DefaultThreadingModel.context.

var DefaultThreadingModel: DefaultThreadingModel = .Asynchronous

This is just what I've come up with in the last 20 minutes or so. Does it make sense? Happy to try and implement it if so.

from brightfutures.

For my needs just an enum is not enough. I need to have a possibility to set a function globally that will determine ExecutionContext on the fly with my own logic.

from brightfutures.

That could still be done by adding another case to the enum, something like:

case UserDefined(ExecutionContext)

So that the implementation in the context method would be:

case .UserDefined(let context):
    return context

And consumers would do the following:

DefaultThreadingModel = .UserDefined({ task in 
    // user defined context in here
})

Edit: it should be noted that this removes the safety discussed above. If this is being done for testing purposes only then my initial implementation is sufficient.

from brightfutures.

I see what you mean. As long as global variable (read setting) is of type ThreadingModel and not a concrete class it would work perfectly for me as well.

from brightfutures.

I would very much like to see BrightFutures work on open-source Swift on Linux. It would be very useful for implementing asynchronous web services à la Scala Play, for example.

from brightfutures.

@andrewcb Already working on this. 95% there and will put it on github later this month. Stay tuned ;)

from brightfutures.

@Thomvis @andrewcb Hey guys! As promised, here is the framework we were working hard on lately and for which we are actively using BrightFutures: https://github.com/crossroadlabs/Express

Feedback is highly appreciated! Thanks in advance!

from brightfutures.

@Thomvis It would be great to cancel the promise, not only the callback of the future.
i.e. once the latest future has been invalidated (so there are no consumers of the Promise anymore), invoke specific invalidation / cancellation callback on the Promise itself.
This is very useful to cancel underlying network operation, for example.

from brightfutures.

@dimazen This comes up from time to time and I agree it can be useful, but I think it should be implemented as a layer around a Future. (Instead of as part of the Future.) Perhaps a combination of a Future and a NSProgress into something that is called a 'Task' or 'Operation'. Does that make sense?

from brightfutures.

@dileping I've reopened #107 to discuss this further. Thanks!

from brightfutures.

@Thomvis, probably, you're right. I think it all because of the signals from the ReactiveCocoa, where you were able to describe action during signal disposal. Later, when all consumers either died or called dispose, original dispose was invoked. However, it seems that I have a wrong understand of the Futures, that are not signals.

from brightfutures.

@jonasman totally agree I think error handling is the most problematic part of BrightFutures and our #1 reason for wanting to migrate to PromiseKit. We have some base library hackery that we're now using but it's definitely not the right way to go, and due to Swift's generic limitations with protocols (ie: ErrorType) we need to create all errors to inherit a concrete base error type - which prevents our code from being generic and used as per the intended language semantics.

from brightfutures.

@marchy i ended up migrating to promisekit.

from brightfutures.

Thank you @marchy and @jonasman for your comments. The goal for BrightFutures is for it fit nicely with Swift and the standard library. Your comments made me realise that instead it is more closely aligned with what I would like Swift to be (e.g. a language with typesafe error handling). This is not the goal I set out to achieve, so the library should be improved.

Thanks again.

from brightfutures.

@Thomvis Can you expand a bit on how reality and how you’d like Swift to be differ? Is it throwing of exceptions?

from brightfutures.

@fsvehla in the context of what we're talking about, I was hoping for typesafe error handling. So you'd have to declare the type of error you'd be throwing in the function declaration. This would enable you to have exhaustive catch expressions without having to use a catch-all. In practice however, I've found the existing error handling to be all I need.

from brightfutures.

@Thomvis Does this mean that you plan on version 5 to not be generic over the error type? I will admit that one of the things that appealed to me when I started using bright futures was the typed errors, but ever since, I found out that a lot of time I have to bend my code around, creating more and more error types and usually resorting to making an errorType with a default case like .DefaultError<error: ErrorType>. It also became clearer when I started working with Rx that it might not be worth it to have strongly typed errors. I was wondering what are you planning for the future, and wether I should just change completely to RxSwift. I just found that for now, it is so easy to bridge between Rx and BF that I am very comfortable leaving both in. Future are just more legible when it comes to writing API code.

from brightfutures.