Ember.computed.literal is blocked on a backwards compatibility story. There are basically three options:
- Breaking change for consistency, deprecating existing behaviour;
- More complicated temporary solution for backwards compatibility (ember only); and
- More complicated temporary solution for backwards compatibility (ember and ember-cpm).
I'm in favour of option 1. I believe @stefanpenner and @ebryn are as well, it would be good to have a decision from @tomdale and/or @wycats.
var l = Ember.computed.literal,
p = Ember.computed.alias; // p == property
// unambiguous
equal(l('Jaime'), p('name'))
equal(p('Jaime'), l('name'))
// ambiguous
equal('string', 'string')
The question is how to default arguments to CP macros: ie whether to interpret
a string argument as a literal or as a property. The current macros interpret
their arguments differently. For example, equal
treats its first argument as
a path and its second as a literal.
We could pick a universal default (either literal or property). @stefanpenner
and I are in favour of literals by default. If the
composable-computed-properties
feature was disabled, the following would give
a deprecation warning:
equal('name', 'Jaime')
And when the composable-computed-properties
feature was enabled (and when it
was "go") that same code would need to be changed to the following to maintain
equivalent semantics:
var p = Ember.computed.alias;
equal(p('name'), 'Jaime')
The PR currently supports ordinal-based argument defaults. This is not intended
to be a user-visible feature, but exists only for backwards compatibility for
the existing ember macros. In this way it is possible to have composable
computed properties enabled, with computed.literal
, while still maintaining
backwards compatibility for the existing macros. The ordinal defaults are
defined as follows:
Ember.computed.equal = Ember.computedMacro('equal', equalFn, PROPERTY, LITERAL);
Although Ember.computedMacro
is user-visible, support for anything other than
literal defaults would exist only for backwards compatibility of the existing
macros.
Option 2 is not quite enough to support the macros in Ember CPM because it has macros that have var-args defaults. This could be supported with a couple additional flags.
Ember.computedMacro('among', amongFn, PROPERTY, VLITERAL)
Any new on that?