On Tue, Nov 29, 2011 at 02:18, Dimitri Glazkov <dglaz...@chromium.org>wrote:
> On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner > <rolandstei...@google.com> wrote:> (FWIW, I'm also not convinced that > it'd have to have high performance > > overhead - in the best case it could be as little as just one more level > of > > indirection.) > > The startup time of a worker is non-trivial. Similarly, the shutdown > won't be trivial. And the memory footprint of a worker isn't trivial > either. If we're aiming for decorators to be fast and lean, we'll have > to think of ways around those costs If we are considering worker-like decorators, then AFAICT it doesn't have to be an actual worker - it's enough if it's a separate object that can be attached and detached. As long as we define the interfaces nicely, FWIW this object could even hold internal state, etc. And in the isolation case this interface serves as a convenient boundary. Now the drawback with this is that the decorator is a separate object - i.e., in its code, event handlers, etc., you can't access the decorated element directly, 'this' is not the element, etc. etc. However, I argue that is actually a feature - and even a requirement if we want to have non-trivial decorators, to address the very problems you stated. In this model, consider the decorator as the glittering glass ornament that is being hung on the christmas DOM tree - it decorates the tree, but it isn't the tree, nor an actual part of it. It can be detached (and potentially even hung somewhere else) without affecting the tree proper. ^_- Roland
