RFC: Improved CP Syntax

[stefanpenner]

No description provided.

[jayphelps]

No mention of Function.prototype.property; is that suggesting it would no longer be the idiomatic way? (Not suggesting for/against, just clarifying)

[stefanpenner]

@jayphelps I suspect it will continue to work for the getter-only and explicitly writable() case

I suppose the explicitly writable case without a pojo, just a FN, on set, should check arity and either call FN with 2 arguments (like today's setter CP) or stomp the CP. This should be handled by my compatibility mode and I suspect this will be deprecated for 2.0

[rwjblue]

s/sinn/sin/

[rwjblue]

Very happy about this proposal. 👍

[cibernox]

I don't know how I missed this.

There is something I can do to help from ember-cpm? Maybe betatest this syntax now?
It comes to my mind something like EmberCPM.computed:

function EmberCPM_computed(){
  var args = Array.prototype.slice(arguments, 0, -2);
  var opts = Array.prototype.slice(arguments.length - 1)

  args.push(function(){
    if (arguments.length > 1){
      opts.set.apply(this, arguments);
    } else {
      opts.get.apply(this, arguments);
    }
  });
  return Ember.computed(this, args)
}

[stefanpenner]

Honestly you could just pr it to ember :) let iterate in a pr and release as soon as it's good :)

[mike-north]

I've got a PR in the works. Should be opening it in a couple of hours

[mike-north]

Ok, I've got something working now :)

One part of the RFC that's going to cause some problems for people (myself included)

• we should keep Ember.computed(fn); as shorthand for getter only

I take this to mean that if I'd written something like this today (which results in a writable computed property)

var MyType = Ember.Object.extend({
  a: 6,
  b: 12,
  half: Ember.computed('a', 'b', function (key, val, oldVal) {
    if (arguments.length < 2) {
       return 0.5*(this.get('a') + this.get('b'));
    }
    else {
      this.setProperties({
        a: val/2,
        b: val/2
      });
      return val; 
    }
  })
});

Once this proposed improvement is made, the function (3rd argument passed to Ember.computed) would not be called for "set" operations anymore. At least in my ember apps, this will be a breaking change in a huge way.

Is there any reason we can't continue to support both?

if a function is passed as the last argument to Ember.computed
   call the function for both get and set, as we do today
else if an object is passed as the last argument to Ember.computed
   call obj.get() to read (calculate) the property, and
   call obj.set() to write to the property

[knownasilya]

@igorT This could be a good replacement for DS.Transform, which feels unnecessary..

[lukemelia]

@truenorth agreed re: not breaking the existing setter approach. deprecating it would reasonable/helpful if possible.

[amiel]

Yes please. I love this idea!!

[cowboy]

I'd much rather see this, a la ember-auto, because as it currently stands, it's very repetitive to specify the dependent properties both in the call to Ember.computed as well as in code inside the getter.

fullName: Ember.computed('firstName', 'lastName', {
  get: function(firstName, lastName) {
    return firstName + ' ' + lastName;
  },
  // ...
});

[jayphelps]

Dogpile! https://github.com/jayphelps/ember-computed-smart-property

fullName: Ember.computed.smartProperty({
  get: function () {
    return this.get('firstName') + ' ' + this.get('lastName');
  }
})

[cowboy]

To support this functionality with less code for properties that are only getters and not setters, but in a backwards-compatible way, maybe an argument could be added to the Function.prototype.property method to enable my requested behavior:

fullName: function(firstName, lastName) {
  return firstName + ' ' + lastName;
}.property('firstName', 'lastName', {args: true}),

Or even a whole new Function.prototype.properties method could be added that just does this by default (with the existing Function.prototype.property deprecated in favor of the improved get/set syntax)

fullName: function(firstName, lastName) {
  return firstName + ' ' + lastName;
}.properties('firstName', 'lastName'),

Or the way ember-computed-smart-property does it, which is also awesome!

[stefanpenner]

fullName: function(firstName, lastName) {
  return firstName + ' ' + lastName;
}.properties('firstName', 'lastName'),

is interesting when a 1:1 between DK and inputs exists forsure.

This type of CP macro would make a great community add-on. The specific RFC existed to primarily remove the arity check from the current CP's as that is obviously mega terrible.

[awj]

I like the general idea, but am concerned about it creating such a difference between Ember.computed and Function.property. Right now they are explained as being essentially equivalent, and the guide covers writeable computed properties using Function.property.

I'm not sure how Function.property could work in the proposed rfc aside from mapping the same function into get and set in the new syntax.

That concern aside, 👍

[cibernox]

@awj The Function#property is just another way to write a getter-only Ember.computed.
One of the reasons behind this RFC was to explicitly disallow having the same function as getter and setter (makes ember internals simpler too) and encourage people to not use the prototype extensions.