Re: [Component Model] Decorator Challenges

On Tue, Nov 29, 2011 at 02:18, Dimitri Glazkov <dglazkov@chromium.org>wrote:

> On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner
> <rolandsteiner@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