emberjs/ember.js — pull request #4185 by hjdivad (2014-01-20 03:25:57+00:00)
Title: Note this depends on \#4182 so that one needs to be good to merge before merging this.

[FEATURE composable-computed-properties] add `literal`, `computedMacro`.

Add two functions, `Ember.computed.literal` and `Ember.computedMacro`, for
helping a) build composable computed properties and b) build cp macros that
are indifferent to their arguments' statuses as either literals or paths.

Consider the current version of `Ember.computed.match`:

```js
includesWat: match('stringProperty', /wat/i)
```

Why is the first argument a path but the second argument a literal? The
basic functionality of `match` should work with both literal regular
expressions and ones that are properties.

With this commit it is now possible to do the following:

```js
var p = Ember.computed.alias, // "property"
match = Ember.computed.match;

var obj = Ember.Object.extedn({
includesPattern: match(p('stringProperty'), p('patternProperty'))
}).create({
stringProperty: 'Behind the WAT!',
patternProperty: /wat/i
});
```

Similarly, the literal/property semantics of macros like `gte` can be
reversed:

```js
var gte = Ember.computed.gte,
l = Ember.computd.literal,
p = Ember.computed.alias;

var obj = Ember.computed.extend({
isGTEBound: gte(l(200), p('bound'))
}).create({
bound: 150
});
```

This support is added for the basic, non-reduceComputed macros in
`Ember.computed`.

Users can easily create similarly literal/property agnostic macros via
`Ember.computedMacro`.

Here is an implementation of ember-cpm's `among`:

```js
among = Ember.computedMacro(function (testValue) {
for (var i=1; i