Return passed in value for set and setProperties in integration test

[trentmwillis]

Address #131.

[rwjblue]

Why doesn't this follow the same pattern as above (returning whatever Ember returns from setProperties)?

[trentmwillis]

@rwjblue depending on which version of Ember you're using, Ember.setProperties might return either context or hash. I think it makes more sense for it to return hash so I standardized around that. I can change it if you feel the other behavior is better.

[rwjblue]

I agree that the Ember behavior changing between 1.x and 2.x is a gotcha, but I'd rather stick with what the framework does here (what if behavior changes again in the future?). Also, the same behavior change exists for this.set (in 1.x this.set returned the context, and in 2.x it returns the value that was set), so we should be consistent between these two.

I think I would prefer to leave the return value undefined (current behavior) for Ember 1.x, and use Ember's return value for 2.x.

This might look something like this:

    context.set = function(key, value) {
      var ret = Ember.run(function() {
        return Ember.set(context, key, value);
      });

      if (hasEmberVersion(2,0)) {
        return ret;
      }
    };

    context.setProperties = function(hash) {
      var ret = Ember.run(function() {
        return Ember.setProperties(context, hash);
      });

      if (hasEmberVersion(2,0)) {
        return ret;
      }
    };

What do you think?

[trentmwillis]

Makes sense to do what the framework does. Not sure I understand the benefit of differentiating on 1.x vs 2.x though.

[rwjblue]

Mostly that the 1.x behavior was not good, and undefined seems better than letting folks rely on the context being returned only to have that be a breaking change for them when they update to 2.x.

[trentmwillis]

Gotcha, seems reasonable. Will update this in a bit.

[trentmwillis]

@rwjblue updated and tests are passing.

[rwjblue]

Awesome, thank you!