Decoration about rfcs HOT 9 CLOSED

@sandstrom The problem with proxies is that they are a leaky abstraction that is also very viral. I'm looking forward to removing the linked piece of code. Even our base Stream class has to have special code to work with Proxies: https://github.com/emberjs/ember.js/blob/master/packages/ember-metal/lib/streams/stream.js#L180-L202.

I would much prefer experimenting with how we can push decoration into userspace.

from rfcs.

@mmun I understand the concern.

If the unwrapping happened in the actions-handling of routes and components instead, is that something you'd prefer? (that'll work equally well for all use-cases I can think of)

from rfcs.

friendly ping @mmun 😄

from rfcs.

@sandstrom Sorry, I missed this. I think that implicit unwrapping anywhere is the codesmell of a bad pattern. So I'm not a fan.

from rfcs.

ES6 proxies (once enough platforms support) will be an abstraction that doesn't have the same issues.

The question is, what should exist in the interim? How do we minimize the leaks and confusions of today

from rfcs.

Decoration is useful in various situations, and a common pattern across languages and frameworks. For decoration to work well with actions unwrapping is desired — which is why this is implemented in Ember.

I understand that you dislike it, but it must not be default. Ember is extensible in many ways, which is great. But this is a place where it's currently hard.

Say, for example, there was a method one could override in routes/components—to act on the action arguments before they were passed on to the action-handler—that would be enough. There wouldn't even be unwrapping in the framework, only the ability to implement it if needed.

from rfcs.

Decoration is useful in various situations, and a common pattern across languages and frameworks. For decoration to work well with actions unwrapping is desired — which is why this is implemented in Ember.

We don't argue it isn't useful, rather in JS today it some with a hefty abstraction leak cost.

from rfcs.

I get decorators. I'm fine with explicit unwrapping. I'm not fine with implicit unwrapping. I've been burned too many times, across multiple languages and frameworks.

Concretely, I never want to think "Is this a controller or is this a model?" ever again.

My opinion may not reflect the opinions of the rest of the core team.

from rfcs.

If it was possible to 'sub-class' the action helper (basically get a chance to act on action helper invocations) adding decorator-unwrapping would be easy. It would also allow for other things, for example logging of all action calls.

This should be possible now, with actions being simple functions one can curry or wrap a function to provide the desired unwrapping-functionality.

Closing this.

from rfcs.