search

cujojs / when

A solid, fast Promises/A+ and when() implementation, plus other async goodies.
Other
3.44k stars 396 forks source link

Simplify lift #275

Open briancavalier opened 10 years ago

briancavalier commented 10 years ago

Right now lift does several things, with no way to opt-out of any of them. The resulting lifted function is still quite fast, but in many cases, it could be even faster. Here are the things it does:

  1. Allows you to partially apply arguments when calling lift
  2. Allows promises for arguments
  3. Ensures the lifted function always returns a promise

I propose that we simplify the situation by doing something about numbers 1 and 2:

  1. Drop partialing entirely. Once the function has been lifted, there are any number of other ways to partial it if you want. I would also bet that most of the time, developers don't use this feature. Mixing it into lift adds complexity and means that lift closes over those args, preventing GC until the lifted function is GC'd. The currently implementation also doesn't check the argument length, so captures an empty array even when no args are being partialed :(
    1. I propose we deprecate partialing in 3.1 (or 3.0.1!), and remove it in 4.0.
  2. I am fond of the promise-accepting behavior you get with lift, but it does come with a cost: we have to run all() on the arguments each time you call the lifted function. Over large numbers of calls to a lifted func, this adds up. It might be nice to allow a dev to opt out in cases where he/she knows the argument-resolving behavior isn't needed. Some options:
    1. Create a new, similarly named function that doesn't resolve arguments. We would also need to handle liftAll, possibly by also providing a variant that doesn't resolve arguments. Or we could expose a public version of the generalized when/lib/liftAll, which accepts a lifter function. I'd prefer the latter, but I don't know if the world is ready for that yet :)
    2. Once we remove partialing, add a boolean param for opting in/out of argument resolving. I'm not crazy about this, but some people might prefer it. Again, we would need to handle liftAll somehow.