JDeferred 2.0 - Roadmap
saturnism opened this issue · comments
- Cancellable - See #88 #98 #39 #123
- Core library
- Android library
- Javadocs
- Update README & Site
- Move some types to package visible but not public - See #90
- Type-safety up to 5 arguments - See #114, #113, #112 @aalmiray
- Core library
- Android library
- Javadocs
- Update README & Site
- Global uncaught exception handler - See #75
- Accept iterable - See #121
- Remove 1.x deprecations - See #120 @saturnism
Nice to have, possibly 2.1:
@aalmiray I feel some of these things were done in the last 2.x branch merge. I updated the list, PTAL.
@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?
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 ;-)"
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 😄
@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(...)
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 😄
Do you feel it should be part of DeferredManager
, or, a new class w/ static methods, e.g.Promises
?
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.
i think we are almost done :D