fix($parse): unwrap promise when setting a field

[chirayuk]

This fixes an inconsistency where you can't call the setter function
when the expression resolves to a top level field name on a promise.

Setting a field on an unresolved promise will throw an exception. (This
shouldn't really happen in your template/js code and points to a
programming error.)

Closes #1827

[chirayuk]

@IgorMinar – @jeffbcross and I looked at the original PR #2854 and cleaned it up into this one.

[petebacondarwin]

This just doesn't seem right to me. How can it be a programming error to try to write to a potentially unwrapped promise? Surely the point of unwrapping it automatically is that the programmer doesn't need to care whether the promise has been resolved or not? If they do care then they have to add their own then() handler to the promise to make sure it is resolved before they can write to it. In that case there is no benefit in unwrapping and the developer might as well just apply their own then() handler and copy the value onto the scope when the promise is resolved.

If you are going to do this then you ought to provide some caching mechanism that will store the written value until the promise resolves... But in my view the whole idea of auto unwrapping (even getters) is a bad one.

[chirayuk]

@petebacondarwin – [1] removed the exception  [2] auto unwrapping promises is probably a bit too much magic. However, given that we're already doing it in the getter, I think we should at least be consistent about it when we do it on the setter.

@IgorMinar – I don't think throwing the exception is a good idea. I've updated the commit to make it equivalent to the way getters work and fixed some edge cases.

[chirayuk]

Examples:

• jsfiddle from issue Bug with asynchronous text field updates #1827
  • broken
  • fixed
• plunker from http://stackoverflow.com/q/16883239
  • broken
  • fixed