Gathering feedback: Support native ES properties for computed properties

[chrisjshull]

This issue is intended to gather feedback on making computed properties gettable and settable via native properties (in addition to the get/set methods).

For example, instead of:

myObj.get('computedProperty');
myObj.set('computedProperty', 1234);

You could do:

myObj.computedProperty;
myObj.computedProperty = 1234;

Benefits:

• No more issues when a native property is swapped out with a computed property, requiring all API consumers to switch to get/set.
  • Alt: no more defensively coding with get/set all the time "just in case". *
• Better autocomplete/discoverability in REPLs and IDEs.
• Less typing.
• More "natural" JS.

* Even if you do this, it can't be applied across the board since you still have to deal with native/non-Ember objects which don't have get/set.

Drawbacks:

• unknownProperty obviously won't work if you don't actually call get/set. unknownProperty is rarely used - classes tend to declare all of their actual properties. However, if your object actually takes arbitrary properties (like an ES Map), get and set will still be there for you.

Again, not proposing the removal/deprecation of get/set. If you like the methods better, or have use of unknownProperty then they will still be there for you. But I think it would be nice to use native accessors for the majority of cases where you don't even want unknownProperty.

[mixonic]

This is likely better as an issue on https://github.com/emberjs/rfcs. Mind re-opening there @chrisjshull?

[chrisjshull]

Whoops. Roger that: emberjs/rfcs#108