Why don't the arguments to create() behave more like setProperties()?
ember.js
Solution
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.
Problem
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?