$q promises does not handle synchronious use correctly

[lee-elenbaas]

If you use promises but resolve them synchronously then the promises does not handle notification and error callbacks correctly
see plunker for sample of this error: http://plnkr.co/edit/Vph0Wt?p=preview

i stumbled across this error when making a mock for something that in reality works asynchronously - but for the tests, sync mock was enough (if only this error was not present)

[caitp]

You have a typo in your error callback in the promise directive. element.test() should be element.text().

Notifications on the other hand do not change the state of a promise, and old notifications are not saved to be sent to newly added thenables (other promise libraries do this as well, although notifications are poorly defined in the promise specifications)

[lee-elenbaas]

This appears to me like a bad definition of what a promise is:

if the promise is already resolved (async or not) and i call its then
method - i expect it to invoke the callbacks synchroniously, or have them
at least queued for immidiete run after my current code completes.
regardless of the digest cycle - ting this into a digest cycle both
diminish the usability by tying libraries that are UI ignorant into the UI.
and lower performance since it forces me to initiate additional digest
cycles in order to make sure my ui is updated properly (especially if i do
not know whether the update came from a ui originated event or not)

On Sun, Feb 2, 2014 at 5:13 PM, Caitlin Potter notifications@github.comwrote:

@lee-elenbaas https://github.com/lee-elenbaas, the callbacks are always
meant to be executed asynchronously (based on the aplus spec) ... However
in angular this is tied to the digest cycle, so a digest is needed before
the callbacks should be called.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6087#issuecomment-33902545
.

[lgalfaso]

@lee-elenbaas I think that there are two different issues here

$q follows http://promisesaplus.com that reads
2.2.4 onFulfilled or onRejected must not be called until the execution context stack contains only platform code. [3.1].
This is, callback methods are called asynchronously

The other part is that you mention that there are parts of your code that may get called inside or outside a $digest cycle. This can be problematic, and something that you should make a clear separation on what is executed inside a $digest cycle and what is not. Trying to maintain code that works both ways is very hard.