Implements _super() for computed properties #1393

Merged
merged 1 commit into from Nov 1, 2012

Projects

None yet

5 participants

@tomdale
Ember.js member

See #607

@wagenet
Ember.js member

@tomdale I imagine you have some concerns about this solution since you didn't merge immediately. Can you share what those are?

@tomdale
Ember.js member

Primarily I just wanted @kselden to review it to ensure I am not causing any major perf regressions.

Additionally, we should discuss if this is even a good feature to have at all. For example, it might surprise developers that dependent keys are not inherited, even if they call this._super(). If we did implement dependent key inheritance, that opens up a whole other can of API worms, because now we would need to provide a mechanism for when you do not want DKs inherited.

@krisselden

we do Ember.meta(obj) in applyMixin() and mixinsMeta() and now here. Maybe it can just be done once in applyMixin, then make mixinsMeta be setupMixinsMeta(m, obj) and pass in the meta to mergeMixins?

@krisselden
Ember.js member

Looks good, we can do another round of perf measuring soon.

I think it is important that the dependency keys be concatenated. I think in general, this goes with moving setters to being their own function, like setFoo, and create calling setters instead of overriding. I think CP logic is becoming more of a first class API citizen, and people should be afraid of overriding without calling super because they are likely to break how a class works.

@ebryn
Ember.js member

I'm fine with this as it is in the short term, but I'd like us to move ahead with the changes we've been discussing: changing the create behavior to call CP setters and splitting out CP setters into separate functions.

@kselden and I both think we could get rid of the CP descriptors and just mark CP functions like we do with observers.

@ebryn
Ember.js member

Also, I do believe that the default behavior should be to concatenate the DKs when super is being called. From my tests, we can use Function#toString to detect this in IE6+.

@krisselden
Ember.js member

If we need proxies to support unknownProperty then we don't need the desc and m.values because we are already hooking get/set through the proxy. also, we probably should add a respondsTo to support the in operator with unknownProperty.

@wycats wycats commented on the diff Sep 21, 2012
packages/ember-metal/lib/mixin.js
function removeKeys(keyName) {
delete descs[keyName];
delete values[keyName];
}
+ function cloneDescriptor(desc) {
+ var newDesc = new Ember.ComputedProperty();
@wycats
wycats Sep 21, 2012

Couldn't we just Ember.create the original descriptor here? @kselden

@krisselden
krisselden Sep 21, 2012

absolutely, good catch, you don't even need the cloneDescriptor call at all

@krisselden krisselden commented on the diff Sep 21, 2012
packages/ember-metal/lib/mixin.js
@@ -90,6 +101,21 @@ function mergeMixins(mixins, m, descs, values, base) {
if (value instanceof Ember.Descriptor) {
if (value === REQUIRED && descs[key]) { continue; }
+ // Wrap descriptor function to implement
+ // _super() if needed
+ if (value.func) {
+ ovalue = values[key] === undefined && descs[key];
+ if (!ovalue) { ovalue = meta.descs[key]; }
+ if (ovalue && ovalue.func) {
+ // Since multiple mixins may inherit from the
+ // same parent, we need to clone the computed
+ // property so that other mixins do not receive
+ // the wrapped version.
+ value = cloneDescriptor(value);
@krisselden
krisselden Sep 21, 2012
value  = o_create(value);
value.func = Ember.wrap(value.func, ovalue.func);
@wycats
Ember.js member

@kselden you mentioned that you wanted to concatenate the dependent keys of super'ed computed properties. Should I wait on that or just accept this?

@tomdale tomdale merged commit 0ac8748 into master Nov 1, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment