[closer-devel] ContextL Layers and persistence

Tue Nov 20 11:16:44 UTC 2007

Hi Ross,

On 20 Nov 2007, at 05:18, Ross Jekel wrote:

> Hi,
>
> I'm new to the list, so I apologize if this has been discussed  
> before and I missed it.

Welcome to the list. :)

This mailing list is still relatively new, or at least hasn't been  
swamped with discussions, so you can still discuss whatever you want,  
and the chances are pretty low that whatever you ask has already been  
discussed before. ;)

> I've been reading the papers by Pascal Costanza et al. and trying to  
> get my head around ContextL. The examples in the overview paper are  
> pretty clear, but I seldom can grasp the usefulness of employer/ 
> person/employee/address models without considering persistence.

The example in the overview paper is not the best one, but the best we  
could come up with at that time. The typical use case that has been  
discovered independently by several people (not by us) is the  
generation of documents in different formats (pdf, html, json, etc.),  
and/or in different languages, from the same object graph. But there  
are also other use cases, and we are trying to come up with new  
examples for new papers...

> While this is not my strongest area, it would seem at first that the  
> decomposition of the data model into layers is similar to  
> decomposition into normal forms or tables in a relational model. If  
> so, would it be possible to create a persistent mixin layer class in  
> the layer class hierarchy to facilitate both automatic Object To  
> Relational mappings of layered slot sets and to allow a mixture of  
> persistent and run-time layers (such as view layers) on the same  
> objects?

This is an interesting idea, and should indeed be possible in  
principle (although it hasn't been tried yet, as far as I can tell).

In the ContextL implementation, each direct slot defined in a layered  
class has a record of which layer it is defined in. Each effective  
slot also records the set of layers of all the direct slots from which  
it is composed. So it is indeed possible to define a mapping from a  
layer to the slots that are defined in that layer. It's then a matter  
of finding a way to define which layers should be persisted and which  
shouldn't.

> Also if one would use direct object persistence such as that in  
> Franz's AllegroCache, could one use the layer system and persistence  
> simultaneously? Allegro's solution, like layers, relies on a  
> metaclass to implement its feature. I've done a little MOP work, but  
> haven't mixed-in two different metaclasses yet. Would it be simply  
> creating a class that inherits from both layered-class and Allegro's  
> persistence metaclass, then supplying the (:metaclass that-class)  
> form in the define-layered-class (I noticed you only supply the  
> (:metaclass 'layered-class) if a :metaclass form is not present).

No, it's not as simple as that. In general, metaclasses do not  
compose. That's the primary reason for the validate-superclass hook in  
the CLOS MOP, where you have to announce which metaclasses are  
compatible and which are not. (And this is not a specific limitation  
of the CLOS MOP, but a general limitation of all metaprogramming  
approaches.)

It could _accidentally_ just work to compose the two metaclasses, but  
normally, you have to review the different hooks of the CLOS MOP API,  
and find out what the interactions are. In this case, I'd expect that  
you at least need to define new subclasses for direct slots and  
effective slots, and provide new methods for direct-slot-definition- 
class, effective-slot-definition-class, and the slot-xyz-using-class  
functions.

Yes, the handling of the :metaclass option in define-layered-class is  
intentional, and is there to allow for such new metaclasses based on  
layered-class. But I can't guarantee that this hook in ContextL in  
sufficient - we simply don't have enough experience with that part of  
the ContextL implementation to claim that we know how all the details  
work.

> From the looks of the macros and what I understand of CLOS, it  
> appears that if persistence as a part of the metaclass on any layer,  
> then it would need to be used on all of them and all layers become  
> persistent, right? Or maybe  don't understand how it would work to  
> have different metaclasses specified on different layers of the same  
> object since with defclass as the underlying mechanism one is  
> redefining the object (is the metaclass for a given layer only used  
> to define the slots in that one layer?).

It doesn't make a lot of sense to make layers persistent because they  
are typically stateless. (Although you can define slots on them, but  
that's probably a different story.)

You probably rather mean to make layered classes persistent. (Right?)  
Yes, it is true that, once you have chosen a particular metaclass for  
a given class, you cannot change that decision anymore. The different  
classes in a class hierarchy can be instances of different  
metaclasses, but class inheriting from each must have compatible  
metaclasses.

The right place to make a distinction between persistent and non- 
persistent slots is in methods on direct-slot-definition-class and  
effective-slot-definition-class on the one hand, and the slot-xyz- 
using-class methods on the other hand. If you take a closer (ha!) look  
at the ContextL implementation, you can see that I use this kind of  
distinction in a few places. For example, a :special slot records the  
fact that it is special in its direct slot definition. The effective  
slot definition is then either a standard-effective-slot-definition or  
a special-effective-slot-definition. For special-effective-slot- 
definition, the new methods on slot-xyz-using-class will be used,  
which triggers the new semantics for special slots, whereas for  
standard-effective-slot-definition, these methods will not be called,  
but the default implementation for slot access in CLOS will be used.  
You could make similar distinctions for persistent and non-persistent  
slots. It all depends on whether you can determine whether a slot  
should be persistent as soon as effective-slot-definition-class is  
called on a slot.

Does that help?

Best,
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