cibernox/ember-cpm — pull request #95 by TrueNorth (2014-10-29 09:30:31+00:00)
Title: Fmt - support for composeable CPMs

I need an extra careful review/discussion here. This PR introduces some inconsistency that doesn't feel right to me.

For previous macros with composeable CPM support, the logic for determining whether a string is a property key or just a string literal value is:

````ruby
given string S
if this.get(S) returns undefined
#regard S as a string literal value
return S
else
#regard S as a property key
return this.get(S)
````
In essence, we have a bias toward assuming that strings are property keys, which is fine because the developer has `Ember.literal` to remove any ambiguity from string literals.

In the case of `fmt`, there's a test that makes things difficult

```js
var MyObj = Ember.Object.extend({
starred: fmt('value', '** %@ **'),
labeled: fmt('label', 'value', '%@: %@')
});

test('returns undefined if *any* of the values is undefined', function() {
var o = MyObj.create({ label: "Name" });
strictEqual(o.get('labeled'), undefined);
});

```

Were I to be consistent with `computed`, `product`, `sum`, `quotient`, we would end up with a value of `"Name: value"` due to assuming that "value" is a string literal after finding that `this.get('value')` returns undefined. It's possible that some peoples' code would break if I were to change this behavior.

My solution here is to add a second argument to the "util" method `getVal` -- allowing certain macros to opt-out of assuming string literals in presence of an undefined property value. This means that users MUST use `Ember.literal` for all literals in the fmt macro, whereas it's only required to resolve ambiguous situations in other macros.