Dathan

Here is what we have done so far which extends that implementation - idea was to submit this as a PR on @pzuraq's 566 polyfill (in line with what you...

Access style is not a concern at all; convention and efficiency of both development and review is the priority (which is why we love ember in the first place). I'll...

Here is a slightly different approach. In this approach, the `@cached` decorator can be used two ways: - `@cached` - as described in 566 - `@cached(propName)` - as desired here,...

...if better differentiation is preferred between caching without a storage property (RFC 566) and with (this RFC), then this could also be done with two separate decorators: - `@cached` -...

@rwblue FWIW, I challenged myself on why I wanted to avoid calling `getCachedValue` in the getter itself as you suggested in your first reply. The reason I landed on is...

One other thought: in the above parameterized version, providing a parameter to the decorator creates a new property on the target object - this may be considered too 'magical' -...

After running through a number of scenarios trying out the various ergonomics, the `@cacheFor()` approach seems the most convenient, conventional, intuitive and idiomatic to Ember. I am updating the RFC...

@buschtoens, thank you - we are using your polyfill and have extended it to support both decorators (`@cached` and `@cacheFor`) locally - I was the one that referenced ["John Dies...

An update - we have been running with the `@cacheFor()` decorator now in a large project for close to a month and the results have been very positive. The simple...

@buschtoens Hmmmm. Something about asking the same question again and getting a different answer reminds me of the adage of doing something again and expecting a different result... ...that said,...