RFC: Getter CP readOnly by default

[stefanpenner]

No description provided.

[lukemelia]

s/choas/chaos/

[stefanpenner]

@tomdale r?

[wycats]

s/unexpeditly/unexpectedly/

[mmun]

What's the status here? Should we rebase and merge?

[stefanpenner]

pending @wycats pings

[cibernox]

Now that the new CP syntax is enabled in canary this should not take much time. I can take care of this since I already know that part of the codebase.

[rwjblue]

@cibernox - I believe that there may be some open questions (just from reading the comments above), but it should be ready for initial implementation (and that could help answer some of those questions...).

[tomdale]

After discussing at the core team, we realized we get this for free when we migrate to the ES5 getter form.

[cibernox]

@tomdale I do have a local branch where I implemented this and IIRC it required very little changes. The concerns of the core team are related with this being deprecated with little notice?

[stefanpenner]

example of the future:

export class extends Ember.Object {

  @computed
  otherName() {

  }

  @computed
  get fullName() {

  }
};

• otherName overrides (current behavior)
• fullName doesn't, as isn't how es5 descriptors with missing setters work.

The benefit of this, is a totally clean upgrade process.

A future RFC will explore and propose the formal adoption of decorators in ember.

[cibernox]

I see it and I like it.

[stefanpenner]

I see it and I like it.

👍

[stefanpenner]

@cibernox someone, (maybe you or me) should write up an RFC for the future integration of decorators.

https://github.com/rwjblue/ember-computed-decorators is a fun example, but since babel fixed some things some serious issues (chaining is broken) now work. We should likely fix that soon, so we can continue to test in userland and the ES2016 spec matures.