Feature creep

[fresheneesz]

So don't this the wrong way, but Q has major feature creepism. This project needs a good solid core that can be built off of. The core is there, but its mixed with a ton of unnecessary sugar and utility functions.

Things that should move to another library

• timeout
• delay
• the generator methods
• all the Promise-for-Object Methods

Things you should outright get rid of:

• second parameter to then - only use catch, reduce cognative load
• get rid of the ability to return non-futures from then
• and progress seems dubiously relvant to a library like this, why include something like this?

Also, naming is kinda an issue in this library. For example, why use fcall and fapply instead of call and apply? denodeify is not easy to type.

And what's the purpose of allowing non-futures to be returned from then? I don't see a need for that, if you want to execute something sequentially after something, put it on the next line. Removing this "feature" would also mean you could get rid of thenResolve, which serves a similar purpose.

If you're willing, I'd like to help you fix up this API, because I think the best async futures library out there (that i've found so far). So please let me know if you're willing to discuss restructuring.

[kriskowal]

I share the sentiment that too many features have creeped into Q, in general. @domenic has also expressed that he would like to punt more into modules. Mark Miller has (sagely) discouraged me to add streaming promises to Q proper. A moratorium is in effect. We are taking measures to make the transition from a one-script-pony to making use of CommonJS modules and NPM, which unlocks some possibilities. We culled a lot of creep in the leap to 0.9 and I plan to do the same in 0.10. Here’s the roadmap.

https://groups.google.com/forum/#!topic/q-continuum/JE6zSshyC5s

There are some obstacles, but the trajectory in general is: make q.js more focused.

However, some things will not be leaving Q core:

• object proxy methods get, post, invoke. However, set and delete would not be missed.
• the second argument of then. catch is implemented in terms of then.
• method aliases for pre-ES5. alas.

The Node and Generator methods are good candidates for punting into modules.

I will entertain debate on timeout and delay. My feeling is that they provide a lot more convenience than cost.

[fresheneesz]

So, in the last day or so, I created a pretty full featured core async library. The concepts in the library are based on Q and fibers/future, though I didn't reuse any of Q's code. I don't want to reinvent all the wheels, but this is one that seemed like needed it. I'd appreciate any feedback.

https://github.com/fresheneesz/nodejsUtils/blob/master/asyncFuture.js Tests: https://github.com/fresheneesz/nodejsUtils/blob/master/tests/asyncFuturesTest.js

[kriskowal]

Some resources for you:

• https://github.com/promises-aplus/promises-spec
• https://github.com/promises-aplus/promises-tests

Some related efforts:

• https://github.com/tildeio/rsvp.js
• https://github.com/cujojs/when
• https://npmjs.org/browse/keyword/promise

I am going to close this issue. The process of modularizing is tracked on other tickets.

[fresheneesz]

So btw, I take back what I said about timeout. Timeout (or some way to cancel the future callback) seems like a pretty basic feature to me now. Do you have any interest in reviewing my work at all?

[kriskowal]

@fresheneesz Unfortunately, I have too many projects in dire need of my attention to be that generous with my time. It occurs to me that you could also get a lot of what I would say upon review from this article:

https://github.com/kriskowal/q/blob/master/design/README.js

I can say that some of your reasoning for wanting a trimmed version of Q is that you may very well have only a subset of the problem that I am solving. I am generally happy to point folks in the direction of API compatible, specification-test-passing variants of Q if they don’t need all the things Q does.

[fresheneesz]

Thanks kris, thats a really helpful document. After reading through it, I don't think it mentioned any corner cases i've missed - tho I'm not doing anything related to arbitrary message passing. Two of the major difference in my implementation is that the promise and deferred is merged (forgoing tho not disabling, the ability to distinguish "authority"), and a promise can't be resolved more than once (doing so will throw an error). Since a promise can't be resolved twice, the problems solved by reducing "authority" are moot - hijacking the promise means you create a bug that needs to be fixed, not a silent error.

I would have used Q, by the way, were I able to resolve promises with full authority. Because I couldn't, it made it much harder to develop the API I wanted with Q.