[closer-devel] slots on layers

[Attila Lendvai]

> What you describe seems to be a classic scenario for using first-class
> continuations. What I already have on my todo list for ContextL is support


to be more precise what we need is only one-shot continuations, which
can simply be done with a lambda plus some macrology without much
overhead.


> for first-class dynamic closures. The idea would be that you can say
> something like (capture-dynamic-bindings), which gives you a first-class
> representation of all special variables, which you can later reinstate by
> something like (with-reinstated-dynamic-bindings ...). Such a dynamic
> closure facility would capture the current representation of active layers
> (because that's in a special variable), as well as, for example, special
> slots both in the layers and in other objects.
>
> (It won't be as general as that, I will have to require registering the
> special variables that you want to see captured, but I think I can make this
> relatively non-intrusive.)
>
> Would that solve your problem?


i think it would, but i still don't see why it is worth it. what you
describe seems to be a lot more complex than if we cloned a new
instance at each change to the layer context. AFAICS, from the user's
POV the two solutions would be equivalent (except the different
performance characteristics), but the implementation of the
make-instance/copy-slots seems much more simple with potentially less
surprises.

as of the performance, these layer prototype instances would have
standard slots that are much faster to access, while layer activation
would be slower, but that's rare (at least in our use-cases). in fact
the entire contextl related performance impact on our application is
probably negligible, and probably most of it comes from the extra
dispatch parameter.

i don't want to say that first class dynamic closures are not useful
in general, but in this situation it feels like too much machinery.

we already have a more fine-grained protocol to restore the dynamic
environment when for example a partial ajax rendering happens
somewhere inside the component hierarchy (components can specialize
the call-in-component-environment method, which is called on the
parent path of the component, one by one). most, but not all of its
usage is restoring dynamic variable bindings that could be covered by
capture-dynamic-bindings, but the protocol is more flexible than that.
it costs us a dozen of extra method calls, but our main priority is
code maintainability/flexibility/reuse, not speed.

i'm sorry if i sounded negative, but i don't have a fine enough
english for this. and i'm just a user anyway, so take it all with a
piece of salt... :) i may even not see the whole picture or an
important detail.

-- 
 attila