[closer-devel] layer slots

[Pascal Costanza]

Hi,

On 26 Nov 2007, at 18:30, Attila Lendvai wrote:

> hi,
>
> while working on a new architecture for verrazano where backends are
> layers, i wanted to add slots for layers.
>
> after looking at the contextl code i ended up with two questions:
> - there's no public api to get the prototype from the layer-context
> on which i could access the slots i've added to my layer

No, but you can always get a prototype for a layer via find-layer. For  
example, you can say (find-layer 'foo) for getting the prototype for  
layer 'foo.

> - the prototype in the active layer-context is not instantiated with
> make-instance but the class-prototype is used which means that layer
> slots are effectively shared among threads (and maybe even after a
> nested deactivation/activation of the layer?)

Yes, layer slots are effectively shared, including across threads.

Layers are actually singletons, and that's intentional. It allows me  
to cache layer contexts and do a quick lookup of contexts on each  
layer activation/deactivation. If layers weren't singletons, I would  
have to create a layer instance for each activation/deactivation,  
because I wouldn't know under what other circumstances an already  
existing instance is already in use somewhere else. (I could do some  
form of layer instance pooling, but that would still be less efficient  
than the current scheme.)

When you define slots on layers, as in the following form, these slots  
are internally actually turned into class / shared slots.

(deflayer foo ()
   ((some-slots :accessor some-slot)))

You can access such a slot via the layer prototype: (some-slot (find- 
layer 'foo)).

There is always ever one such slot per layer.

> the test files suggest usage like this:
>
> (assert (eq (slot0 (find-layer 'test-layer)) 'foo))
>
> but find-layer also simply calls class-prototype after a find-class on
> the layer name, which again is a shared instance. or am i badly
> missing here something?

No, you found out right.

> maybe it's ok to call class-prototype because there'll always be a
> distinct class? if so, how does it interact with caching?

The fact that layers are singletons actually enables the caching  
scheme of ContextL.

If you really want to create the 'same' kind of layer several times,  
you can use subclassing on layers:

(deflayer foo1 (foo))
(deflayer foo2 (foo))
...

In this case, the slots from 'foo are still shared among all those  
layers, but you can redefine such slots in sublayers according to the  
semantics of overriding shared slots in CLOS.

However, that's probably overkill. See more on that in my next post.


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium