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 arguments to create(). See http://jsfiddle.net/zJQJw/2/

I found the best workaround for this is to call create().setProperties(properties) instead of create(properties), but this seems like an unnecessary gotcha to me. I realize it might break some apps at this point, but would you consider making create() behave more like setProperties()?

My motivation for asking for this is that init() will be called before setProperties() when using the create().setProperties(properties) pattern. This hasn’t been a big problem yet, but I can see this being undesirable in some situations. This is a completely contrived example, but maybe you can see what I am getting at? http://jsfiddle.net/QJ8vX/2/

The only reason I can see for maintaining the current behavior is to do instance-specific overrides of setter methods. But in those cases you could just as easily do MyClass.extend({ overridenMethod: ... }).create(properties)

Would a change like this be considered for Ember 1.0? Or do I just have the wrong idea about how Ember’s object model should work?

Answer 1

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.