Skip to content

Instantly share code, notes, and snippets.

@hjdivad
Created February 10, 2014 20:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save hjdivad/8923385 to your computer and use it in GitHub Desktop.
Save hjdivad/8923385 to your computer and use it in GitHub Desktop.

Ember Computed Literal Backwards Compatibility Blocker

Ember.computed.literal is blocked on a backwards compatibility story. There are basically three options:

  1. Breaking change for consistency, deprecating existing behaviour;
  2. More complicated temporary solution for backwards compatibility (ember only); and
  3. 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.

Background

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.

Option 1: Breaking Change

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')

Option 2: Backwards-compat Ember Only

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 3: Backwards-compat Ember + Ember CPM

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)
@cibernox
Copy link

cibernox commented Oct 6, 2014

Any new on that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment