Deep Watches up the prototype chain no longer fire

[petebacondarwin]

This is due to a change in the semantic of angular.copy at b59b04f.

The problem with deep watches is that oldVal is created by copying newVal but now both have the same prototype and so if a value on the prototype changes both oldVal and newVal change together so it is not possible to trigger a watch handler.

See the following two plunks:

At master : http://plnkr.co/edit/NUDQR9ZqYLi8kreoLcrk?p=preview
At 1.3.0-beta-13 : http://plnkr.co/edit/3cappcs8WVjBM6X1vsRn?p=preview

[petebacondarwin]

One solution would be to create a new flattenedCopy() function that is only used in $watch...

[gentooboontoo]

@petebacondarwin what do you think of 3b9656c? It's a quick proof of concept to try your idea, not sure if this is the right way to do it. Current tests still pass. I have to make a specific test based on your plunks.

[petebacondarwin]

It looks pretty good. One question is where else this has an impact. At least it would also provide a migration path in case anyone was using the old copy and expecting this flattening behaviour.

[myitcv]

What problems does this create out of interest? Were there test breakages as a result of b59b04f?

I can't actually foresee a situation where I would want to change the prototype (admittedly I'm coming from a background of prototypes being used almost exclusively for classes in CoffeeScript) after object creation.

[IgorMinar]

upon further discussion it seems that this is not a a problem in real world scenarios as far as we are aware. closing..