Ember Should Deprecate `incrementProperty` and `decrementProperty`

[jherdman]

As we move into a world where we can access properties via POJO getters, incrementProperty and decrementProperty stick out on EmberObject as relics of time when a lot of convenience methods were provided for you. Outside of special case scenarios, these methods could be replaced as such:

this.counter += 1;

this.counter -= 1;

Therefore, to reduce magic and surprise, I'd like to recommend the deprecation of these methods.

An alternative approach is simply to do nothing given that #337 indicates that EmberObject, itself, will be deprecated at some future date. Thus any work done in trimming it down may be considered wasted effort.

[miguelcobain]

Let's not forget about

this.counter++;
this.counter--;

(when increment is 1)

I believe that maybe deprecating this should be tied with the deprecation of .get().set()?

[pzuraq]

Whether we deprecate EmberObject or not, slimming it down will make the transition process easier. I'd definitely be for deprecating special helper functions like these.

[t-sauer]

Isn't this.set here to stay? So you would still need to do something like

this.set('counter', this.counter++);

[simonihmig]

With Ember 3.1 we can omit the .get(), but not the .set() (yet). So when dealing with CPs, the given examples would not work AFAIK. I believe they would override the CP instance instead of invoking its setter.

IIRC, it was mentioned that .set() should also fade away sometime. Then these helper methods should go as well, for sure!

[miguelcobain]

I said .get(), but I meant .set()!

[jherdman]

@t-sauer good point. I think this is okay as it's a net reduction in API "needless" surface area.

[Benjy1979]

incrementProperty is only incrementing by 1 BY DEFAULT.

[jherdman]

I'm starting to have second thoughts about this. A clear candidate using my thinking above is toggleProperty. The thought I'm working through now is that these methods wrap up some fairly common things that Components do. Is removing these methods, with the goal of scoping down overall API surface, really worth it if these are methods Components commonly reach for?

[jherdman]

Closing due to lack of traction as an idea.