[BUGFIX beta] CPs check presence of getter function

[cibernox]

Today I spent some time tracking a cryptic stack trace.

It turns out that I typed years: computed('age') instead of years: computed.alias('age')

This will check the presence of the getter function in creation time, instead of failing when you try to access the property, usually 10 minutes after writing it when you have no idea where to look.

[cibernox]

Bugfix is probably not the best tag, but I couldn't find a better one.

[stefanpenner]

is a CP \w setter only considered valid?

[cibernox]

I wouldn't consider it valid. Does ES5 to have setters without getter? I think you can have readonly properties, but not writeonly, do you?

[stefanpenner]

Does ES5 to have setters without getter?

yes

[cibernox]

@stefanpenner You can define only a setter, but that's because the getter will have a default (just getting the property). In other words, defineProperty accepts writable flag to make something readonly, but there is no way of making something writeonly.

A computed property needs to execute something.

[stefanpenner]

A computed property needs to execute something.
Hide all checks

Actually it doesn't, as the return value of the set populates the cache. Subsequent reads read from the cache. Yes this is order specific but it could be used (i beleve)

(I'm not trying to be pedantic, rather enumerating the possible scenarios this assertion without modification will cause grief for)

I suspect we can just assert that either getter or setter exist, and my concerns are covered.

[cibernox]

That cache we are thinking we might remove?

Seriously speaking, I can change the assertion to check that you either pass a getter or a setter, but think that a CP with only a setter is a case so weird that we should make it less ergonomic than the most common scenario, a brainfart on the line of:

age: computed('years'),
// or
age: computed({
  het() {},
  set() {}
});

[stefanpenner]

Seriously speaking, I can change the assertion to check that you either pass a getter or a setter, but think that a CP with only a setter is a case so weird that we should make it less ergonomic than the most common scenario, a brainfart on the line of:

yes weird, but it is possible today. So we should work within the constraints our users currently have, not impose additional.

If the assertion checks that at-least the getter or the setter is present, i think that is a win.

[rwjblue]

age: computed({
  het() {},
  set() {}
});

We can also assert if we find any keys other than get and set, which would catch this.

[stefanpenner]

We can also assert if we find any keys other than get and set, which would catch this.

good idea

[cibernox]

Ok, added assertions for:

• Computed properties need to receive either a function or a configuration object as last argument. It guards against:

computed('nothing')
computed('array', []);

• Computed properties must receive at least a getter or a setter.

computed('emptyobj', {  })

• When it receives an object, only get & set are allowed keys. Guards against:

computed('nothing', {  
  het() {},
  set() {}
})

Any more idiomatic way of checking this last one. Also, is there any reason to use Ember.isArray in the case instead of Array.isArray?

[rwjblue]

Seems to die when loaded by Phantom (see Travis failures). Might be the for ... of ...?