[Openmcl-devel] [off-topic] Adding a slot to a class using the MOP

[james anderson]

good morning;

On 2013-04-23, at 09:49 , Hans Hübner wrote:

> On Mon, Apr 22, 2013 at 7:32 PM, Ron Garret <ron at flownet.com> wrote:
> I need to dynamically add a slot to a class using the MOP.  There  
> doesn't seem to be a standard add-slot method, so I figure I need  
> to use something like ensure-class.  To do that, I need to  
> reconstruct the argument to :direct-slots from the existing class  
> definition so I can add a slot without disturbing the existing  
> slots.  Before I went down this rabbit hole I thought I'd ask: is  
> there a better/easier way to do this?  Surely I'm not the first  
> person to want to do this.
>
> You are asking for "better/easier" ways, so here are some options:
>
> - Have your users inherit from a base class that provides the  
> default primary key slot, use a slot option and the MOP to give   
> users the ability to designate a different slot for the primary key  
> (Pascal pointed that out).  The MOP will then mostly used to allow  
> the extra options.
> - If you dislike the requirement for an explicit common base class,  
> modify the class inheritance list of classes using your metaclass  
> to include the common base class holding the primary key slot.   
> This is not quite as straightforward as it sounds because you'll  
> have to find out whether the primary key holding base class is  
> already in the ancestor list of a class before you add it.
> - You can also avoid storing the artificial primary key in the  
> user's instances altogether by putting it into a (weak) hash table  
> keyed by the instance identity.  This may actually be the "easiest"  
> option, although you stated the requirement that some classes would  
> use another slot as their primary key.
>
> For the first two approaches, maybe https://github.com/slyrus/xml- 
> class/blob/master/xml-class.lisp gives you some implementation hints.
>
> "Adding a slot dynamically" neither sounds like the "best" nor the  
> "easiest" option.

the described use case requires to associate identifiers for an  
external representation with model instances in such a way that the  
association is orthogonal to the model representation and operations.  
there are good reasons to support this. for example to provide  
retrospectively support for persistence by reachability - that is,  
over instances of classes for which the declarations are fixed and  
for which extensions are either not desired or infeasible. the  
described example illustrates a case where the identifier is atomic -  
whether the generated uuid or the declared instance property, but, in  
general, such a protocol would also need to support compound or  
otherwise computed identifiers, for which no direct representation is  
present in the application model.

in this situation, as hans lays out, the alternatives are two. one  
can extend the model's internal representation independent of  
application definitions. in which case, retrospective capabilities  
leave no alternative but to "resort" to mop operations. necessarily  
independent of class definitions and likely in definitions managed by  
the storage interface. if mop operations is not desired, then the  
other alternative is to support the protocol at the interface to the  
storage layer independent of the instance representation. either the  
store provides for this itself, or one implements it in the access  
layer - for example, with the weak hash table approach.

is there another abstract alternative? if not you will have to take  
your pick.

best regards, from berlin,