Why don't the arguments to create() behave more like setProperties()?

Question

Something I find very counter-intuitive about Ember is you can overwrite a computed property setter functions ( http://emberjs.com/#toc_computed-properties-setters ) with the ar

Answer 1

It's may be a dirty hack, but it's works for me.

Em.Object.reopenClass({ 
   create: function(config) {
       return this._super().setProperties(config); 
   }
});

Answer 2

The main reason why we've pushed back on this change is that it makes it impossible to override properties that are defined on base classes as computed properties. For example, in Ember.View, the template property is a computed property:

template: Ember.computed(function(key, value) {
  if (value !== undefined) { return value; }

  var templateName = get(this, 'templateName'),
      template = this.templateForName(templateName, 'template');

  return template || get(this, 'defaultTemplate');
}).property('templateName').cacheable(),

When creating a subclass of Ember.View, you may want to override this definition with an explicit template function:

Ember.View.create({ template: Ember.Handlebars.compile('...') });

If the computed property doesn't handle the setter case, this attempt to override the computed property would be a silent failure.

If we made this change, it also introduces other questions about whether observers should trigger for properties passed into the create method. Both are possible to implement, and there are strong arguments for both approaches.

In the run-up to 1.0, it seems reasonable to consider an approach that would:

• change create to use setProperties semantics
• add a new API (override or createWithOverride) that would retain the existing semantics, in case you explicitly wanted to override existing computed properties
• suppress observers for properties set due to create (or decide not to)
• find a way to detect and warn about attempts to use the create API with computed properties that do not implement setters.

I would need to discuss it more, and consider the implications to existing apps, but it is definitely something worth considering, as it is definitely a pretty big gotcha for new developers. The fact that we needed to change the behavior for ember-data is a pretty good clue that something isn't quite right.