JDeferred 2.0 - Roadmap

[saturnism]

• Cancellable - See Add a cancellable convenience method #88 Cancellable support #98 Cancel functionality  #39 Cancelable callback #123
  • Core library
  • Android library
  • Javadocs
  • Update README & Site
• Move some types to package visible but not public - See Remove unnecessary visibility modifiers from interfaces #90
• Type-safety up to 5 arguments - See Handle multiple results with type safety #114, With multiple results it is hard to access the cause of the failure #113, MultipleResults is not type safe #112 @aalmiray
  • Core library
  • Android library
  • Javadocs
  • Update README & Site
• Global uncaught exception handler - See Add Uncaught Exception Handler #75
• Accept iterable - See 2.x Ability to take Iterable based on #104 #121
• Remove 1.x deprecations - See 2.x - Removed deprecated functionalities #120 @saturnism

Nice to have, possibly 2.1:

• Settle - See How to wait till all promises complete #79, Initial implementation of DeferredManager.settle #128
• Race - See Initial implementation for DeferredManager.race #127
• Convenience methods in Promises Add a cancellable convenience method #88

[saturnism]

@aalmiray I feel some of these things were done in the last 2.x branch merge. I updated the list, PTAL.

[saturnism]

@aalmiray the exceptions handlers needs to be registered with every promise, specifically in AbstractPromise in the triggerXYZ() methods. If we pass the reference in a constructor, that'll mean every subclass will have to get it and will change a lot of signatures. Moreover, promises that aren't created by DeferredManager won't register.

Alternatively, we can have a static global class that holds the exception handler and every promise instances would just refer to that. This would work w/ all promises even those created outside of DeferredManager. wdyt?

[aalmiray]

The problem with a static global location is thread-safety and synchronization. We could "cheat" by using ThreadLocal but can't guarantee it will work 100% of the times. My MO when braking APIs between major versions is "if we're going to break compatibility we do it in the most spectacular way in order to ensure a better API, that is, sometimes we have to burn bridges while supplying fusion powevered hovercrafts to cross the river ;-)"

[saturnism]

on the other hand, associating it to every deferred object might be too much for a crosscutting concern though. let's discuss more at baselone 😄

[saturnism]

@aalmiray regarding the convenience method, the best I have so far is Promises.resolve(...) and Promises.reject(...). I can't think of anything else at the moment. Should we still include it?

They can also be part of DeferredManager, e.g., dm.resolve(...)

[aalmiray]

I think so, as it's the only way to support resolved/rejected promises with Iterable for example. that way there's no longer a need to update the current impl to be able to handle a resolved value, as it'll be wrapped with a Promise 😄

[saturnism]

Do you feel it should be part of DeferredManager, or, a new class w/ static methods, e.g.Promises?

[aalmiray]

My gut feeling tells me it should be part of DeferredManager for now, as that's the place where Promises are created, other than explicit construction via DeferredObject. There are only 2 methods for now, don't think that warrants a Promises or PromiseUtil utility class just yet. If it comes to that, we can re-route DM to the utility class at a later stage.

[saturnism]

i think we are almost done :D