emberjs/ember.js — pull request #4753 by mmun (2014-04-22 02:48:08+00:00)
Title: Revert "[BUGFIX beta] Total invalidation of arrayComputed by non-array d...

...ependencies should be synchronous"

This reverts commit 7af8beb0bb9e484ab7427b447f6b6dbb76b4aad8 which attempted to
bring the semantics of ReduceComputedProperty closer to those of ComputedProperty
but inadvertently introduced a performance regression in some cases.

ComputedProperty guarantees that any `set` calls that occur before a `get` call
will be run before the `get` call is triggered. For example

```javascript
var obj = Ember.Object.extend({
foo: Ember.computed.alias('bar')
}).create();

obj.set('foo', 1);
obj.get('foo'); // returns 1
```

For technical reasons ReduceComputedProperty does not offer the same
guarantees.

```javascript
var obj = Ember.Object.extend({
filtered: Ember.computed.filter('things', function(n) {
return n % 2 === this.get('parity');
}).property('things', 'parity')
}).create({
things: [0, 1, 2, 3, 4, 5]
});

o.set('parity', 0);
o.get('filtered'); // returns [0, 2, 4]

o.set('parity', 1);
o.get('filtered'); // returns [0, 2, 4], but we expected [1, 3, 5]

Ember.run.next(function() {
o.get('filtered'); // returns [1, 3, 5]
});
```

The commit fixed this issue but introduced a performance regression. Every call
to `set` would eagerly force a recomputation of the reduced computed value,
instead of deferring the work until a subsequent `get` call. This was seen
most prominently in Ember.computed.sort with sortProperties that changed
quickly. You can find more details about the regression at:

https://github.com/emberjs/ember.js/issues/4712
https://github.com/emberjs/ember.js/issues/4740

Conflicts:
packages_es6/ember-runtime/tests/computed/reduce_computed_test.js